According to security researcher, book author, and serial entrepreneur Vivek Ramachandran, we’re at a pivotal moment in cybersecurity. Gone are the days of relying on URL/domain analysis to identify threats. With so many employees spending the majority of their time in Chrome, Edge, Safari, or Firefox , Ramachandran thinks the browser is where security products need to innovate.
Ramachandran sat down with Michael “Roo” Fey, Head of User Lifecycle & Growth at 1Password, on the Random But Memorable podcast to discuss the latest browser threats and AI. Read the interview highlights below or listen to the full podcast episode for a breakdown of recently identified vulnerabilities in Outlook, Apple Mail, and Gmail, and to learn more about how SquareX’s browser-native security solution works.
Editor’s note: This interview has been lightly edited for clarity and brevity. The views and opinions expressed by the interviewee don’t represent the opinions of 1Password.
Michael Fey: Tell us a little bit about yourself and your journey in cybersecurity.
Vivek Ramachandran: I fell in love with cybersecurity roughly 25 years ago. This was the time when DDoS attacks were happening on Yahoo and AltaVista. I suddenly heard that this German hacker going by the name of Mixter had created an attack tool called Tribal Flood Network. I downloaded it, opened it up, and understood nothing. And that’s when I became super fascinated with understanding how something like this works.
I started learning C programming, assembly, and all of that and eventually went to university. I started trying to build my own attack tools and then was lucky to join Cisco Systems fairly early. I was able to work in their Layer 2 security team as a programmer doing a lot of very deep tech features. But I soon realized I was great at breaking security rather than making it.
“I soon realized I was great at breaking security rather than making it."
That’s when I completely pivoted my career, discovered a bunch of zero-day attacks, and the Cafe Latte attack, which breaks into Wi-Fi networks. I spoke at DEF CON and at Black Hat for many years and eventually, I figured the only way for me to keep doing research is if I quit everything and started teaching and made some money on the side.
Fifteen years back, that’s how I started. Eventually that grew into me creating a wireless monitoring product, which I primarily sold to the DoD (Department of Defense). Afterwards, I did another company called Pentester Academy, which was red/blue teaming exercises in the cloud. That one was acquired. Now SquareX is my most recent obsession!
MF: SquareX is a browser-native security solution – what does that mean? What’s the problem that you’re solving?
VR: If you look at the enterprise today, employees are spending over 90% of their time in the web browser. Almost all SaaS applications, everything that they do is running via the browser. This is where attackers are also targeting employees – when they’re on their browsers using third-party websites, social media, and whatnot.
For a very long time, SASE, SSE (secure web gateways) were trying to detect these attacks in the cloud and filter all of that traffic. Now, we feel there’s a pivotal moment where unfortunately, attackers are very easily able to bypass it. The only way that you can now go about detecting these client-side web attacks is by having something running natively in the browser itself.
Of course, natively in the browser would mean, would Google have to integrate us? And that’s a very high bar. So SquareX runs as a browser extension and that browser extension is looking at DOM (Document Object Model) events, browser events, user interactivity, and then detecting attacks, which it can block or isolate. That’s what we are building and that’s the reason we call ourselves browser-native and a browser-first-class citizen.
MF: The browser extension APIs have become so rich particularly with Safari adopting the same methodologies as Google and Firefox. So I have to imagine you can build a pretty rich product in that space.
VR: Yes. And one of the things we also did was use WebAssembly in a very big way. We used Rust compiled into WebAssembly. That’s how the machine learning and algorithms are running in the browser itself at super-fast speeds. WebAssembly was literally built for this purpose.
MF: You mentioned we’re in a landscape now where most people are spending time in the browser, certainly within the enterprise. What’s the nature of the attacks these days that you’ve seen targeting the browsers?
VR: Traditionally, we’ve all been used to seeing attacks like spear phishing, as an example – and I’m guessing that is one of the attacks that you guys would be most concerned about, given it’s still not a passwordless world yet.
What has happened recently is attackers are starting to use trusted domains to host malicious websites. So now you can go to sharepoint.com, office.com and create a malicious spear phishing website right there.
“Attackers are starting to use trusted domains to host malicious websites."
This will bypass anything which is using URL or domain analysis. And for a very long time, the whole industry just completely banged on domain reputation as a way to decide what to allow or disallow, at least in the enterprise.
Now, if you start to compound it: identity attacks, SSO, SAML hijacking, browser-in-the-browser, adversary-in-the-middle. All of these new attacks have their lifecycle in the browser itself. Previously, when you had a credential stealer, something would end up downloading. The malware would have to get installed and it would start to read Chrome’s password file or whatever and then try to send all of that.
Now you don’t need to do that. You can go full attack cycle in the browser. I’ll give you a fantastic example of attacks which are happening right now. Any time that ChatGPT comes up with a newer version, attackers start saying on social media: “If you install this extension, you’ll have access to the latest premium version.” People just go and install browser extensions. You and I know extensions have superpowers but most people don’t and that’s an easy way for data exfil at this point in time. All of these attacks are really what SquareX is looking at and solving in the browser.
MF: How does SquareX do this? What’s the mechanism that you’re using to be able to detect and prevent these?
VR: When we started looking at this problem, there was so much data in the browser. Browsers have rich data. DOM is changing probably thousands of times a second. There are browser events and whatnot.
We first built out some way by which we could make sense of all of these events. We ended up creating a bunch of MutationObserver layers, which really is looking at DOM changes but only those which have relevance from a security perspective. Then we look at browser events, only bubbling up those which have security significance. We look at network requests but only those where we are looking at SSO-, SAML-based interactions, file downloads, and things like that. We have an entire event layer which is looking at this crazy number of interactions but then just bubbling up important features and metrics that are interesting to us. Those end up going into algorithms, which are running natively in the browser itself. That is really where we begin and look at attack detection.
I’ll give you one simple example. Let’s say somebody is downloading an Office document, which contains a malicious macro. Now, at this point in time, you’re at the mercy of your endpoint security once you download it, because browsers like Chrome typically – unless it’s a very known threat, something which is already fingerprinted – isn’t going to block it.
With SquareX, here is what happens. Everything we do is browser privacy safe, so when that Office file is starting to get downloaded, we actually keep it in browser memory, almost creating a lightweight file system. Then we extract the macro from that Office document and run macro analysis right there. The moment we figure out there are suspicious functions, then we can go about warning the user and actually isolate that using file isolation in the cloud, which we built out as well.
“When that Office file is starting to get downloaded, we actually keep it in browser memory, almost creating a lightweight file system."
MF: I want to go back in time just a little bit. You’ve contributed to some research that’s exposed vulnerabilities in Outlook and in Gmail. Can you walk us through some of those findings and the implications of them?
VR: The way we stumbled upon this is when we were looking at exactly this: an in-browser file analyzer. We started downloading arbitrary files from all locations and seeing if our detector was able to detect it. And then all of a sudden, my team said: “Hey, why not just check if webmail scanners are actually scanning Office documents and Excel files and all that really well?”
“We were so surprised to see that all of those emails were getting delivered."
The team sent known malicious Office documents to Office 365, Google Workspace, Apple Mail and you won’t believe it – we were so surprised to see that all of those emails were getting delivered. This is the most unbelievable one: you could actually take an existing malware, which is on every threat feed, and it’s actually an Excel document with a malicious macro doing a download and execute. All you had to do was change the metadata of the author name and it would bypass, which meant, as crazy as it sounds, all these platforms were doing was literally just hash comparisons.
MF: How long ago did you discover all this?
VR: This was barely five to six months ago. Many of these vulnerabilities still exist today. I could show you a live example of an Office document with a malicious macro, which even VirusTotal (antivirus scanner) would say there is a problem with and would absolutely go through Gmail, Office 365 and all.
What I suspect is, these mail providers are getting millions of documents probably every second. There’s only so much cloud processing power that they can throw at each of these documents before it starts to become prohibitively expensive. I’m guessing they would have to create an isolation pod, because they can’t mix documents from multiple people and analyze it on the same system. So, some isolation container, something going on, and all of this is expensive to run at scale. This is really where we felt like a lot of this processing done on the endpoint in the browser is way more scalable than trying to do this for millions of users at the same time in the cloud.
MF: Yeah. Why do you think mail providers haven’t pushed for these types of protections yet?
VR: I think there are multiple possibilities. One is, of course, the sheer amount of processing power required if you had to go through millions of documents like we just discussed. The second interesting thing is it’s not just mail providers, but even instant messengers like WhatsApp Web, Telegram and all of these. I think many of them, what they try to do is peer-to-peer encryption. And when you try to do P2P, the big issue is then you yourself can’t analyze what’s really happening in between.
“Anything sitting on the network, trying to monitor, trying to intercept, is going to become more and more difficult."
WhatsApp Web and Telegram and all of these are fantastic ways to send malware, because it reaches the other user with nothing ever happening on the network – because there’s no safeguard possible. That’s really where we’ve started to sense that, as we are moving more towards this P2P encryption world, anything sitting on the network, trying to monitor, trying to intercept, is going to become more and more difficult. Really, where things have to be, is where the data is finally delivered, which is in the browser.
MF: Despite massive investments in secure web gateways and SASE, we’re still seeing nation-state attackers evading detection. Can you talk about some of the new attack techniques you’ve observed?
VR: We did a DEF CON main stage talk where we talked about 21 architectural vulnerabilities in SASE, SSE, and secure web gateways, which are unfixable even to date. This was to the biggest vendors. We even coordinated the release. Now, what is the real problem? The problem is all of these secure web gateways came at a time when just monitoring SSL traffic was a win. You remember 10 years back when the world was moving from HTTP to HTTPS? Maybe 14 years back, I guess.
Fortunately for them, at that point in time, you could look at network traffic and infer application layer attacks, because all you were looking at was simple HTML, CSS, and JavaScript.
Today’s web apps are massively complex. Everything is a thin client, API-driven with client-side views changing multiple times in a second. This is really where looking at network traffic to uncover application attacks, unfortunately, is no longer possible. Secure web gateways lack context of user interactivity.
I’ll give you a simple example. Let’s say a malicious website monitors a clipboard, copies the data – maybe that was credit card information – and sends that data. A secure web gateway doesn’t know if this is a form submission, clipboard data, just session data, or gibberish? Without context of data source, data origin, there’s absolutely no way that you can apply any sensible policies on a network device.
Another example is a drive-by download. You are on a site. A download triggers. How does a secure web gateway know that this was not a user clicking and downloading versus something downloading asynchronously? I could go on and on, but fundamentally, the problem is, without understanding what’s happening on the user’s browser, without having that data, you are essentially blind to state. And, if you don’t know the state of the application, the state of each of the windows, there’s no way that you can uncover modern application layer attacks.
“Without understanding what’s happening on the user’s browser, without having that data, you are essentially blind."
MF: I want to go back to AI for just a minute. You talked about this attack where people get offered browser extensions to access the latest premium features. How do people avoid falling victim to these pretty cleverly disguised attacks, and certainly where there’s not an understanding of, as you said, the level of power that comes with a browser extension?
VR: I think, unfortunately, what’s happening is we are reaching that stage in technology where tech is so complex that – forget the average user – even an average technical user may not be fully able to understand what’s really going on. You and I know browser extensions in and out, but if you talk to even a really good technical person, they might not understand what superpowers an extension would have.
With AI, what I’m starting to see is, things are compounding, because even in the pre-LLM era, we were still relying on our senses to decide what is fake and what is real. Compounding deep fakes, there’s absolutely no way now that you can look at something and say: “Is this something created by a human being or an AI?” Scams are going to be a lot better.
One of the interesting things we did with AI is we used code LLMs to write all the exploits, which I put out there for the secure web gateway. The key assertion I was trying to make was that attackers can now come up with proof of concepts (PoC) way faster than enterprise security products can come up with patches, which they have to test before deploying. While an attacker can deploy a PoC every second, he doesn’t care. He only has to win once. I think it is going to get worse before it gets better.
MF: How do you see the future of browser security evolving over the next few years and what role does SquareX play in all of this?
VR: I actually feel what’s going to happen is the browser has to get more intelligent, because, if you think about it, that is the access device to everything. That is really where we almost see browser security evolve to become a security assistant to the user. It’s only in the browser that you’re viewing the web exactly how the user is viewing.
“The browser has to get more intelligent."
You have a “sitting on the shoulder view” of what the user is doing, viewing how websites are getting presented to them. My assertion is that the best way that any security product sitting in the browser can grow is almost to start to become an AI security assistant – to start solving any problem which the user would encounter while he’s working on the web. That is how we are also thinking about growing SquareX: grow with the user’s need to be able to differentiate all of these attacks, whether AI or non-AI related. Be almost like an AI security agent for the user.
MF: Where can people go to find out more about you or about SquareX?
VR: For SquareX, sqrx.com. I had to go through a lot of pains to get that four-letter domain, as you can imagine. And for me, I’m on LinkedIn and on Twitter: Vivramac. I tend to post a lot more than I should on social media, so if you want to get abreast with the latest updates from SquareX or from me, I think our LinkedIn or SquareX’s website is the best place.
Tweet about this post