It's not that simple. Collecting 250Gbps of uplink is not that simple. The attack vectors are simple in principle, but carrying it out...
Here's next year's fine vector: You write a nice iphone or android app and persuade fifty million people to download it. But unknown to the owners of those mobile phones, it also has a hidden evil feature: If the phone has the screen off, is charging and is on a WLAN, then it can participate in a DDoS if you direct them to. The phone's owner won't notice, but if enough phones are charging and each can contribute 2Mbps of upload, you could collect 250Gbps at the target.
And tracing it back to that app will be very difficult.
Google/Apple will catch you in hours/days and all your work goes down the drain. Also its hard to get 50M downloads, not worth the time.
There is already an established economy of botnets. They work like this:
1. There is a hacker group (usually ex-USSR or China) that is actively monitoring 0 day vulnerabilities. They usually target internet connected devices which are from companies that dont give a damn about updating them after they are released. This is the case for most budget routers, "smart" things (lamp, frigde, vacuum, doorbell,..).
2. If they find a nice one (e.g. one that affects millions of shit-tier $40 routers), they set up port scanners and infect as many as they can.
3. Rent the botnet on darknet sites, there is already an established pricing for them, for example $1000 for 1 hour of 1000Gbps DDOS. You just pay them in crypto and tell what to attack.
Tell that to the Hola and Honey extensions. They're known to be a botnet and for this kind of abuse for years yet you can still find them everywhere in the App/Play Store...and _so_ many tech related youtube channels keep advertising for them blindly, it's ridiculous.
I had heard that Hola was possibly some kind of malware, but this is the first I'm hearing that Honey (I'm assuming we're both talking about the coupon-code extension) is like that too.
I just figured Honey was kind of like spyware, collecting information about what people bought online.
Honey redirects their users' traffic to their own ad-identifiers and replaces them in the codes/script tags. That's how they make money. Personally this kinda classifies as a CnC because they can redirect traffic at demand for websites remotely.
If you look at the extracted codebase, it reads like a malware implant that's designed to give some blackhat traffic for their own army of clickbots.
Hola on the other hand is basically an origin obfuscator, and they route traffic through other browser extension instances.
That's how they "unlock" websites and what their proxy feature is about. Note that this is an http proxy only, and hola sniffs all local passwords and cookies, too.
So they can abuse your user account for lots of stuff without your consent, and they did that in the past, too. (A search for DDoS and hola reveals lots of incidents and news reports)
While I agree that Honey is borderline spyware and extremely privacy invasive, that's a little different from claiming it is malware facilitating DDoS attacks.
Echoing the sibling comment, I knew Honey was WAY-too-good-to-be-true from the seemingly infinite marketing resources being poured into it - but I had no idea it was a botnet (?!). Further insight highly appreciated!
These things are easy to do in principle (most readers here can write that evil payload, or learn how to do it quickly) but there are real practical challenges to getting the code to run on millions of strangers' computers/phones/dsl routers, so most of the code that's actually deployed that widely is beneficial. Happily.
On iOS the OS does not allow apps to do this, you basically can only use the OS APIs to do networking in the background so clever tricks are right out, and it is throttled.
What's the solution to this? If millions of devices are each sending 2Mbps to some target, what can the target do? It doesn't sound like there's a program that would be able to identify something so diffuse.
The open nature of the protocol carries with it an implicit trust. Any client may join and speak to any other client and be heard. It is a social contract, just as we have "in real life."
Imagine someone knocks on your door. You can choose to not answer, but even considering the choice costs you cognitive bandwidth. As long as you're within earshot of your door, a knock will cost you attention.
We have solutions all across the spectrum, from putting up a "no soliciting" sign, to arresting bad actors. But what if you have a riot outside your front door (a DDoS)?
The rioters you mention are remote teleconference zombies. There are those that can stop them with only relatively small effort - ISPs and less directly transit providers, but it is against their interests.
Perhaps a better analogy may be robocalls with spoofed numbers.
I think you understand why edpnet.be has problems now.
What they usually do is try to write packet filter rules and drop packets as close to the millions of origins as possible, plus call the networks where the sending devices are and say things like "could you please call your customers and tell them to unfuck their {phones,dsl routers,…}"
remote triggered blackholing the networks from which the ddos comes is very effective for small DDoS's. but its a very crude methods that drops entire /24's from being able to reach you.
I think part of the difficulty is that just receiving or denying the traffic can consume all of your resources. It really has to be denied at the ISP levels before it reaches your router.
If you can examine traffic on a network from which attacking traffic originates, you can see that it's coming from a phone.
Then you could see which app by either limiting or deleting apps one at a time, or you'd need two sources, then just see which apps the two sources have in common.
When you have 250 Gbps, it'd be simple to capture a fraction of a second's worth of traffic, then write a script to fire off emails to network admins of every IP involved and ask them to look in to it. Out of hundreds or thousands of messages, you'll get a few humans who'd look in to it and would be helpful.
If your nontechnical neighbour's ISP calls and says "you're participating in a DDoS, will you please find out which device behind your NAT is sending the traffic and fix whatever the problem is", do you think your neighbour can fix it in five minutes?
They could, which mitigates the attack without locating the actual source (that is, your app) and leaves you free to use the same app again for another attack next week. Maybe even taking care to use a different subset of the devices where your app is installed.
rp_filter (reverse path) does. Problem is it's a leaf(ish) router solution: if the src ip is not in the locally attached subnet, drop it. Not every isp sets this up though, for whatever reason.
limiting your spoofability to ips by the same isp doesn't help, especially since many will have multiple subnets so it won't help your target's ability to filter the packets out
Getting this kind of behaviour past review is simple, and malevolent apps do happen.
Google has a clever technique for detecting them (after review) and it's good, but slow. It has a decent chance of detecting the app after a few attacks, and works by analysing which apps were installed on phones just before a factory reinstall.
Here's next year's fine vector: You write a nice iphone or android app and persuade fifty million people to download it. But unknown to the owners of those mobile phones, it also has a hidden evil feature: If the phone has the screen off, is charging and is on a WLAN, then it can participate in a DDoS if you direct them to. The phone's owner won't notice, but if enough phones are charging and each can contribute 2Mbps of upload, you could collect 250Gbps at the target.
And tracing it back to that app will be very difficult.