Hello all, I'm a first time poster here and hope to follow all rules.
I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps
** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack.
We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do?
The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable.
MCI Comm/Verizon Buss
Comcast Cable Comm
I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January.
If you are curious and you operate/manage one of the network mentioned above, please write to me at email@example.com from your job email to confirm the identity. I will then forward you the DDoS details.
365 boul. Sir-Wilfrid-Laurier #202
Beloeil, QC J3G 4T2
NTP Monlist was what, 200x? 100x amplification attacks are soooo 2013.
I doubt many will fall for your Rolodex expanding exercise though, sorry. (
Do people still have Rolodexes? )
I am just trying to grasp what is similarity between networks on the list
and why it doesn't include, say NTT or Cogent.
You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your “service” is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way.
Sometimes you folks say that (mis)use amplifiers for “testing” purpose is not a problem because those services are open and publicly available on the Internet. Come on… if I leave my car open with the key inside it doesn’t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine.
I don’t need to explain why using botnets is illegal and immoral, right?
Man, it is up to you decide between cyber crime and cyber security (https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose). Now, we are also looking to you on http://booterblacklist.com/>. Thanks!
Depending on which bit of PSINET Jean is talking about, that could be Cogent.
I admit that I have a lot of guts.
Not sure who said that I am a booter or that I operate a booter. I fight booter since more than 5 years and who would be stupid enough to put his full name with full address to a respected network operators list? Definitely not me.
I want to help and fix things and I am not the kind of person to break things.
I am saying!
As far as I understand you are offering DDoS attacks as a paid service, right? Some people would say that you offer DDoS for hire. What is the difference between your service and a Booter service. Only a “validation" that your client is “stress testing” him/herself does not make you legal. Sorry man but you can NOT claim yourself as a legal/moral acceptable stress tester if you misuse devices on the Internet, such as amplifiers, webshell, and botnets.
Although you don’t consider yourself a Booter, you are one of them!
I leave up to you the definition of stupid.
You're claiming to be able to generate more than 10 times as much traffic
as the largest DDoS ever seen in the wild whilst 3 months into a position
at a company that sells 'self-DDoS' services for testing purposes.
In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no
technical details, you can surely understand the skepticism.
I apologize for my previous email.
After a second thought it might sound like it's a booter even though I want to offer something else.
I don't want the conversation shifting toward business when we talk about a new DDoS technique that operate at Layer 3 with amplification power x100. I disabled the "booter" service and will review this offline with my lawyer. Thanks for pointing this out.
Now back to this new DDoS technique. If it can amplify at Layer 3, it could potentially be use in conjunction with the already known Layer 4 amp DDoS like dns, ntp, ssdp, snmp, etc. It doesn't need to be use in conjunction but it could.
Like mentioned earlier, it doesn't need spoofing so any device could be part of it.
Google already acknowledged through their vulnerability program that there is something interesting there and they are still assessing the risk/impact. They suggested me to start privately disclose this with some big players. I thought NANOG would be a good start. I guess they also need time and maybe partners to test and validate all this data.
Cert-CC is also aware and they are also working out something on their side.
I am in good faith here and time is not against us. I discover something new that I want to share properly and I am not here to make business.
Let's wait and see if his stated message of being here to discuss technical matters of the vulnerability with the aforementioned carriers bears anything out. If not, don the torches.
I just reviewed our data at http://radar.qrator.net provided network list.
I am highly skeptical.
<tapping my feet neurotically>
Exactly my thought.
Tingling sensation "this is some kind of fraud".
These are layer-7 reflection/amplification attacks - i.e., application-layer - *not* layer-4.
Skepticism is of course warranted with such bold claims and little public information to back it up.
Aside from the 'that's not layer 4' point that's already been made, I feel
obligated to point out that if you were advised to 'privately disclose to
some big players', the NANOG list is pretty much the exact opposite of
that. This is a very public list.
My paranoid brain doesn't want to completely discount you ; but the onus is
on you to provide proof. Are you willing to send me the details to this
address if you're not willing to provide any specifics to the list?
Maybe he's found what's already known and posted 2 months ago (and every 2 months?)
on nanog, the TCP 98,000x amplifier (which is a little higher than 100x), among
dozens of misbehaving devices, all >200x amp.
(Table 1's 'total load risk', (not calculated; Im using potential #hosts * amp factor)
shows that each protocol listed curiously all have similar values, within 40%.
Little too curious, in fact. I'd expect distribution across a few magnitudes.)
He said, "There is no need for spoofing " so it wouldn't be that one.
Respectfully: you're not well known to us as having identified earth
shattering vulnerabilities in the past. We hear about utterly
unimportant "priority one" events every single day, so without enough
information to assess whether you're looking at is something new,
important or even possible within our various architectures, few of us
will be inclined to take you seriously.
We're all too familiar with the consequence of giving credence to
people who say "believe me" instead of offering verifiable fact.
I respect that you're trying to help, but "I have something important
to tell you, please contact me off list" is not the way to do that.
And if it turns out we should have listened and kept this secret as
long as possible, well, that's on us.
Jean sent me details. I won't share the link or password to it based on his
request, but he hasn't found anything new, and it's not even amplification
What he did was send 1500 byte ICMP packets with a max TTL at an IP address
that is not reachable due to a routing loop. No amplification is occurring
; it's just the same packets hanging around longer looking for free food
because of the TTL.
I think he _assumed_ amplification was happening because link utilization
between his lab routers doing the looping was increasing. Totally expected
when you're using --flood and in a lab environment where the TTL entering
the loop is still above 250.