How to Pull Off a Near Undetectable DDoS Attack (And How to Stop It)

Good afternoon everybody. Thank you so much for coming to Bside San Francisco 2025. I'm here to introduce our final headliner for this particular theater. My name is Nicolina. So afterwards, if you have any questions, let me know. Um let's see. Mr. Simon Wickman's who actually just moved here three weeks ago. Welcome. Welcome. Thank you. I'm very excited about what he's going to be speaking to. How to pull off a near undetectable DDoS attack and how to stop it. So please, sir, Slido, if you have questions while the presentation is going on, we use Slido. Um he he generated this QR code for us. Please feel free to type in there. I'll read the questions if we have time. um

and that this gentleman will answer them. So, please sir, we're excited. Take it away. All right. Well, thank you everybody for coming. Um I have a an annoying special request. I have one sales guy who is currently at our booth and he was supposed to be here to take pictures. Um but he isn't. So, I would like to ask if any one of you can take a nice picture and either email it over to me or tweet it at us or whatever. That would be awesome. My mom would love you. Thank you very much. Well, actually, well, whatever. Just do it anyway. Thank you. All right. So, hi everybody. I'm Simon. I'm the founder and CEO of

Seaside. Um, previously I used to be at Microsoft Cloud Fran Versell. Um, I don't want to make this into a sales pitch, but it's important to give you some context here. I'm uh Seaside is a client side security company, and client side security is one of those terms that people are like, what does it mean? Well, we focus on detecting and blocking dependencies that you may have on your website when they misbehave in the browser of a user. Um, and as a result of that, today I'm going to be talking about some pretty significant really bad attacks that we see, especially a very difficult to detect DOS type attack. So, first things first, what is

client side security? Um, honestly, think about it this way, and this does sound salesy, but it is pretty pretty important to put it this way. We spend a lot of money on firewalls, and historically we have, it's been going on for like the last 30 years. We spent a lot of money on serverside security tools. I would say half of the floor upstairs is serverside security tools. We also spend a lot of money on endpoint protection for ourselves and for our staff. But can any web developer in here raise their hand that 100% knows how their application behaves in the browser of a user? Exactly. Nobody really knows how their application is behaving in the

browser of a user. And guess what? Bad actors know that. They can very easily find ways to execute their attack in a place you're not watching. Um, and this happens all the time because ultimately browsers are just becoming more and more powerful all the time and more and more things are browsers like progressive web apps or more things that really don't have to run browsers run browsers. Browsers are everywhere. And we've heard that so many times. It's a bit of a cliche, but us hackers that think about security, um, there's one specific thing we really love, and it's a world where the specification and the actual implementation, there's a severe gap in the middle. And that is definitely the

case with browsers. Um, the thing with client side attacks is they are fully dynamic. You can very easily target 1% of users in a specific geography after office hours. That is the whole purpose of a client side script that it can be served conditionally and that is something that is able to excfiltrate a lot of interesting data. Uh but mostly given this gap between browsers also allows you to behave differently in specific browsers. So older browsers getting specific scripts but therefore also using specific vulnerabilities in specific browsers. Just in Q1 this year and this is the last thing I'll say that sounds market thingy. We've spotted 300,000 client side executed attacks, net new ones on websites. So 300,000 unique

websites actually being more spec more more precise. These were attacks that simple malicious redirects or would try to exfiltrate session tokens of some sort. Um excfiltrating things like credit card data, injecting malware, crypto mining, you name it. And that is just Q1 this year. And it's not that we're the best company in the world yet. We're a year old and we are making our detection capabilities better every day, but this is a pretty substantial number. It's not unlikely that one of your websites that you ever worked on in the past at some point has one of these. So, let's talk about DOS. I mean, I could ask if everybody here knows what DOS is, but I'm just going to assume

that everybody understands how a DOS attack happens and what it is. So, where do attacks usually actually come from, right? Um my experience working at Cloudflare of course we learn a lot about this and we saw a lot of real practices here. Um often it's botn nets just coming from compromised cloud hardware right so trying to find some type of service vulnerability that allows them to inject some malicious payload finding some leaked SSH or whatever just getting a machine on a cloud pretty easy to detect. I'll talk about that in a second. The other method is botn nets on IoT devices. Somehow founding a vulnerability in an IoT device or a very cheap Alibaba IoT device that people

unknowingly add to their network at home is actually being used for that. That is a very common one as well. Um and then of course malware injected devices, the most common of them all. Your grandfather downloads something on its laptop, that laptop is dosing other things or there's an exploit in there that can get used for that purpose. So how we protect against that today? And sorry, I have to look at my notes here to make sure I don't miss anything. Um, you can rate limit things, right? And rate limiting has been around for ages. We all know how to do that. But the question is, what do you rate limit on? The IP address, uh, client side

cookie, uh, account ID, some type of value. What you rate limit on really matters. In the world of DOS, you're usually down to either rate limiting on the IP, on a specific type of fingerprint you can find on layer three. Um so the is the OSI tech uh is here or um you can for instance rate limit ASN that you don't often see right and so you do some type of pattern matching um over what is normal safe traffic for you um you can also just be a little blunt and block IP addresses that you don't want for instance there is no reason for AWS IP addresses to be on my website until you find out that there are

reasons for AWS IPs to be on your website um that tends to be a very hit or miss way of doing things. Um or you can do things like let's look at the actual packet size, right? So let's say um the baseline of an IP packet to my web server is this size. Well, often DOS attacks are pretty simple. They're empty packets. Um they're a little smaller and they're often the same size. So you can do something like that. You can do things like just encryption that was used or things like client hello fingerprints, but now you're going up the OSI stack uh higher and higher and higher and result you end up spending more money having to do more expensive

compute to figure out whether this is a legitimate request or not. Then finally, something that is kind of the last resort is I can't figure out what the heck this is. I don't know whether it is a normal request or not. Let's just chuck a capture at it and hope that that stops the bad guy. Well, we all know in the age of AI, you can very easily build bypass tools for goss. So, we're going at a pretty fast pace towards a really nasty world where DOS attacks, the age old thing that we've suffered for like 30 years on, um, is back and is even harder to prevent. And there is one specific type of DOS attack that we have

seen numerous times in the wild that I honestly don't even know how to begin feeling like figuring out a way to stop it. So let's talk about what makes it hard to detect DOS attack. So first things first, let's say I'm a bad actor and I need to build the ultimate DOS attack. I want to use real human browsers, a normal Chromium browser. Let's just ignore that. That could be really expensive and difficult for me to do, right? But let let's just if I could get my hands on a whole bunch of real human browsers, that would be great. Cool. Now the next thing is let's find a way uh wait yeah so that would basically mean I

want to make sure that nobody actually has to install anything on their laptop right because if you get people to install something then you need to create value creating value creates marketing marketing cost a lot of time you need to get a whole bunch of people convinced that they need to download something downloading malware well in some cases easy but it's a bit of a mess right let's use residential IP addresses as well let's like try and avoid using something that could very easily be tracked back to a server farm of some sort. I kind of don't want to deal with IoT devices because I know that they're running weird light operating systems that are quite easy to fingerprint

honestly. Um, and let's make sure that that attack happens at a level layer 7. So that whoever is unlucky enough to be the DOS protection company for this vendor that you're targeting uh has to spend a lot of money to actually figure out full layer 7 execution postSL decryption whether this is a legitimate thing. So no malware inclusion as I said scripts. Okay, I'm going to jump ahead there. So the answer is let's just chuck an advert on an ad network, right? Um, this is the thing where client side security becomes real. If you want to distribute scripts around the world, when people ask me, "How do the client side scripts actually end up on my

site?" Well, I can talk about security incidents like injecting it through an npm package or somebody managing to hijack some marketing tool or whatever, but it's actually way simpler. Ad networks are literally JavaScript distribution networks. Sure, the most reputable ad networks of them all. They have some type of systems in place to prevent unsecure behaviors. They probably have locked down some of the APIs you have access to, but that's far from every one of them. There's a whole industry of secondary ad networks that are not really caring about security. So, it's not that hard to distribute a JavaScript across a bunch of browsers. You can also think about, okay, let's find some unpatched serverside CVs in client side scripts

that already exist. Um I think many of us have heard of heard of the polyfill attack last year. Um somebody just bought a domain name from an organization out of China quite organized. I can talk about that in detail. They had that domain for 6 months before they pulled off a really visible attack. We don't even have to go there. There's a lot of 20-year-old marketing companies out there from random places in the world that have very severe server side TVs that you can just exploit that have been around for years. Um quite scary but the truth. You can also just as I said use an open source dependency npm. Um or you can find and this is the most easy of them

all. It's kind of ridiculous but yes S3 buckets do expire and people do forget to remove them from client side code. Uh in fact we have a little tool on our side that when we see one of those S3 buckets we automatically register it again because we know that it's just a matter of time before somebody does uh and we'd rather have it oursel. So let's assume you've now found a way to put JavaScript in a whole bunch of browsers. Looks like there's plenty of ways to do that, right? I'm going to give you a couple of examples of thing we've seen in real life. So this is an iframe flooding method. So it's a hidden

iframe. You wouldn't visibly see anything, but is actually trying to fully render the targeted site like a normal human would, like a normal browser would. This is not going to look any different from you as a normal human going to the website. Let's jump to another one. So this is just a fetch XHR method. This would be a lot easier to catch because often well this wouldn't mean the actual full page is being rendered, right? So you can recognize this is just an opportunistic uh fetch, right? So this is easier. You could stop this at some level. I mean at layer 7, you could probably figure out this is not a real browser. You could go the web worker based

floating route where you literally just create a backend web worker. Um, and that thing is just patching away. You can even combine it with that iframe method. And then there you go. You just found another way to use potentially hundreds of thousands of devices in your botnet. And then number four, this is the window open method but hidden. So we've all seen tab floods. To be fair, nowadays Chrome is doing a good job at hiding them often. Don't forget, it's not because it's hidden that it's not working. Um, there are definitely ways to execute this very easily. And there you go. There's now a bunch of tabs that exist that you don't even know that

exist. And they are rendering pages. As you can see here, it's basically just fetching the victim's domain. And those are just four examples, but there's a few other methods that basically come back to the same concept. So what do these attacks except for number two do? Well, they basically have the ability to bypass pretty much every bot, every type of DOS detection that exists. It's coming from a human device from a human browser doing full rendering of a page. How are you going to stop it? I don't know. Um, you can even add a little library there that bypasses potential captures that are on the pages, right? It's not that hard. It's quite lightweight nowadays. Even we've

lit just bypassed all of layer 3 anyway by this method. Thing is that I as a security engineer if I saw this traffic come in it would be completely indistinguishable from a normal human. Um and so the result is this happens a lot. Um, I did not realize when I started this company how often we were going to see this, but a lot of these DOS style scripts are being distributed across ad networks in really heavily offiscated JavaScript code. Um, looking like normal things. Um, looking like normal ads, heavily offiscated, but you can still make sense of what they do. They proxy requests to multiple domains. So, sometimes they even have a redirect method where they point to an attacker

own domain with a redirect server at the end. That's a thing. Um, and I mean, of course, ad networks that are in really high traffic websites, unfortunately, we also have to recognize that a really big chunk of the internet is gambling and porn. And so, a lot of ad networks that are reputable do not want to be on those. So, we are directly driving these really large traffic websites into the hands of ad networks that really just don't care about security, that don't have the revenue to deal with that, that don't care by design. And this is one of those things. So, let's do some quick math, right? Let's say you found a way to get 10,000 active laptops to load

your JavaScript. I wouldn't consider that very hard. And let's say you can get each of those browsers to 100 requests a second. Well, now you ended up with a million requests a second. You could take down pretty much any medium-sized business very easily. Um, amplify that, adjust the numbers, and you basically can take down an entire country. That's not that hard. And so that's where we are. Um, what you can do as a site owner. Look, I had to think about this because I called it what you can do about it. The thing is you can stop it at the source. That's really I think the responsibility of the web. Uh, if you have ads on your site,

if you have client side scripts on your site, you should be considering what am I doing, right? What am I doing to protect myself, protect my customers? It is ultimately my dependency on my site. I am responsible for it. Um, but you're also protecting the rest of the internet. So, your responsibility is to think about these scripts. Well, first things first, everybody here probably heard of CSP at some point. It's an absolute headache, isn't it? Um, but it does exist and there's a reason why it exists. And so, at some point, we just got to get real and recognize that um even a loose CSP is better than no CSP at all. Right? Then we can talk about sub resource

hashing. I think it's a funny concept that that thing is still considered a real solution cuz let's face it, a lot of these scripts are just really dynamic nowadays and SRRI does not like handle that at all. There is a really brand new specification to SRRI coming. Um it's in the W3C. A lot of people are talking about it. Um it also adds a reporting endpoint so that violations are not happening quietly. I don't like that too much this approach but you can use it. It's one of the method methods that you can use. You can also just really make sure that you're darn sure that the stuff you're using on your site is secure. I have

never seen a client site injection come from Google Google Analytics, right? I can blame them for how they handle data all day long. Sure, but that company has their security together, at least today, right? There's no wood, but I would say knock on wood. Um, just don't trust some weirdass script from some small ass startup or something you read on Reddit that can boost your SEO. You'd be surprised with how many marketeteers fall for that. And then the last thing or actually just to the previous point, ask yourself the question, what is your process for adding a client site script? Right? Your marketing intern comes to you asks, hey, can you add this thing to

your site? What's the process? What are you doing? Are you just checking it that day to make sure it looks okay? Do you check it every week? Do you check it every month? Do you check it once a year? You can ask yourself that question. Just in general, I think we are not doing a good enough job about understanding the network requests that come from our sessions in browser of users. That is something that I highly encourage people to log. There are various ways to do that as well. So that is a good thing to do. Little drop, we also have a free tier. Um I don't want to make this a marketing thing, but

ultimately you can get rid of a lot of these issues with our free plan. But then on the other side, it's like, okay, let's say you're the target of this type of DOS attack. I I mean the only real thing here is a capture but as I said that even that doesn't work today. So we have to start thinking about like I think the real way to do it here is stopping it at the source. Um and that's where we are. My quick final thoughts thing is client side security has been completely neglected for a very long time. Browsers are super powerful. We see so many things happen all the time. It's crazy how creative you can

get with these types of attacks. And we've seen everything from data accessful to crypto mining to literally people using other people's browsers as storage places for fun. They could do that. You got web assembly in browsers nowadays. You can do all sorts of funky stuff with that. Um, and it's also very cost effective. Of course, let's say you chuck an ad on a cheap ad network that gets onto a 10,000 laptops. That's going to cost you less than a botn net on a dark web and it's going to be harder to detect. Um, equally you can then use it for anything you like really. It's really not science fiction. That code that I showed you earlier, it was only

really a few lines and I think any mediocre JavaScript developer could have written that. Um, but just in general, it's time to think about your application. Like how does it behave in a browser? Does your front end team know pretty pixels? Sure. But what else? What are those 2,000 other dependencies that you have in npm? And do they have the ability to inject something client side? Well, yes. Right. So, gatekeeper. And those are my thoughts. Sorry for the dark subject people. I'd love for people to recognize that this is a really painful thing. But sometimes I come across these attacks, I'm just like this really should not be a thing, but it is a thing. Anyway, um with that,

let's go through some Q&A. Thank you. Wasn't that amazing? Thank you so much. We appreciate you. He's going to actually read his own questions. He's going to filter them out in case he doesn't like your questions. Just saying. That's so far been pretty easy on me. So I'll start with a very small personal one. What makes you want to move to North America for staying in London? Is there a greater need here? The thing is at the end of the day when you start starting an early stage company like myself. Um I hired people that I worked with before. There were great people. Um but you cannot build a company from London the way I'm trying to do it now.

Um, here in San Francisco, when you go to the local coffee shop, you will get bitten in the leg by uh the dog of a company that is able to be a million-dollar company. Um, like the dog of the owner of a company that can be a million dollar customer for you or um the CTO of a company who could literally acquire you, right? Or somebody that could really give you advice in how to take your company public. In London, a lot of people like to act like that. They definitely have the aura and the ego, but uh yeah, they don't have much to talk about really. So, that was my reason to move. I mean there's a whole

bunch of by combinator content on why to move to San Francisco. Um it definitely is a good place to be to scale a company and to do things well. Um how does IP reputation and thread feeds fit into this? Uh answer not at all. These are my mom's and my granddads and my IP addresses. There is no thread feed that will catch these IP addresses. It's just people on the internet. So unfortunately not much you can do there. If there was a fingerprint, then of course chucking that on a feed would help a whole bunch of people, right? But there isn't from what I can tell. So, um, it's hard to distribute knowledge on this. Why are these instead of crypto

miners an attacker? That is a very good question. It depends on what you're trying to do. If you're really angry at a company and they are really well secured, you may be invested in finding a way to dodo them and thinking, well, this is going to be very hard to stop. Of course, it's really bad and it's illegal and you never should. Um, but sometimes people have those motivations. mining crypto through ad networks. That is something that a lot of those ad networks do know is a big problem and they have built detection capabilities for. I would say it's actually the easiest one to catch because you can just monitor things like CPU and memory

in sandbox environments. Uh and usually these are not they're conditional. Um but yeah, I mean it's different motivations. DOSing a company has the aim of taking them down and doing financial harm to them. crypto mining through client side scripts in random people's browsers that's usually not directed at one company. Um, cool. Then, uh, made you think, well, is creative bad, but kudos to Okay. What's an attack you've seen that made you think, whoa, that's creative bad, but kudos to you. And why? That's a good one. Um, one we did a blog post about I thought was particularly bad. It was a clientside script that really conditionally after x amount of seconds of waiting uh would

pop up a Google branded Chrome branded you must update your browser window that was completely un indistinguishable from the real thing and when you pressed update it would download malware. Um that was one that was like well somebody really took a good course on how to design like Google here. Um so not that creative. I think this DOS thing is one of the more creative ones because I didn't think about it when I started this company. I've seen a lot of client side attacks in my past career and I mean usually it's excellation of some type of sensitive data or the crypto mining stuff but um was new to me. Um I also get why

these scripts didn't look particularly malicious did they? I mean wasn't that they were using specific APIs that make alarm bells go off. Um but yeah at the time we didn't see them so I didn't even know that that was a thing. Uh will you be at the seaside after party? Of course we'll be at seaside after party. There's a big party at 221 Main Street. Uh we're co-hosting it with Socket and a bit a few other companies as well like Arjette and Incident.io and also on Wednesday we're doing one for RSA. Uh so let me know is mining crypto uh cross-ite scripting a big threat. Um I mean true cross-ite scripting here is the word that makes me a little

confused but I mean there was a high time for this but as I said the the libraries that were used for crypto mining because by the way a lot of client side attackers are I would say a little lazy. They reuse code a lot. A lot of the libraries that do client side crypto mining are so standardized and easy to detect that they're not really that big of a thing anymore. Um, don't forget that this client side space is mostly powered, at least our competitors, not really us, by thread feed intel, right? So, Risk IQ and Virus Hotel and those types of companies, they will crawl the internet and try and find scripts that do crypto mining. Um, and I

wouldn't say they do a great job at it, but it's really a matter of time before this newly register registered domain gets scanned by those. And especially with Google acquiring risk IQ with um virus total, they know how to crawl. They're very efficient at that. So I wouldn't be surprised if there's more advanced detections there. So crypto mining, I think there's always limited lifespans on those attacks. But then to my point, attackers know that they will just move to a different domain two weeks later and then there you go. And then avoid detection all over again and we're back at square one. Don't we all love a cat and mouse game? No. It's so interesting. Cool. Uh that was the last

question. I questions for me. so far. Don't we love that it's like five minutes early, last session of the day, we can wrap up our Sunday. Awesome. I'm so happy he's on time and early.