He ran the attack from midnight to 7AM, so there were no humans watching.

IPs were rotated on every single request, so no rate limiter caught it.

We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.

We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.

Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.

We never thought this could bite us this way.

Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.

Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.

This is a big deal. Payment processors can ban you for allowing this to happen.

Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs, so many legitimate users appear to come from low reputation IPs.

Turnstile is a reasonable solution in its normal form, though the 'invisible' option still lets a lot of them through. Another thing that works, surprisingly, is looking for "webdriver" usage. Despite being easy to strip out webdriver fingerprints, we find that the majority of automated attempts do not bother to do this. Adding more steps, honeypots (with an immediate short term IP ban), etc. also have an impact. It becomes a game of piling up numerous defences in a sort of "Swiss cheese model".

After 12 hours, the pace of emails came to a halt, and then I started receiving emails to made up addresses of a American political nature on the same domain (I have wildcard alias enabled), suggesting that someone was perhaps trying to vent some frustration. This only lasted for about half an hour before the attacker seems to have given up and stopped.

Strangely, I didn't receive any email during the attack which the attacker might have been trying to hide. Which has left me confused at to the purpose of this attack in the first place.

The Internet was carefully designed to withstand a nuclear war and this approach, being adopted en masse, is slowly turning it into a shadow of its former self. And despite the us-east1 and multiple Cloudflare outages of last year, we continue to stay blind to this or even rationalize it as a good thing, because that way if we're down, then so are our competitors...

It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.

Here are some interesting additional information from the attacks we analyzed:

* Email bombing as a service is a thing, where you can buy 10,000 credits for $10 and easily bomb target inboxes with over 2000 emails per hour.

* Most all email bombing attacks starts in the morning, between 8-10.

* Most common day of attack is Friday

[0] https://www.xorlab.com/en/

[1] https://www.xorlab.com/en/blog/from-chaos-to-control-insight...

My conclusion is to move from WordPress software as fast as possible, every WordPress site I manage gets bombarded by bots.

> While the victim is drowning [...] the attacker is doing something else.

In the past months some personal mail accounts on a mail server I administer were victim of something that looked similar to what's described here.

Hundreds of mails apparently originating from various (legit-looking) random public web services, support requests, issue trackers, web contact forms etc. For example, a good part of them was from Virginia Department of Motor Vehicles (as in something like "thank you for filing a document #123 with us").

To make things even weirder, they were not sent directly to the address, but according to message headers were bounced through Google Groups (each time I checked the relevant group was already deleted). So as far as I can tell it was not the mail address hosted on my server that was being entered into those websites.

No phishing links, no attached malware, no short advertisements snuck into a text field etc. Just a huge amount of automated replies from "noreply@" legit entities.

I've seen several of these attacks and spent some time investigating them. To my knowledge these were not associated with any other malicious activity, like the author of the article mentions. If anything they were just a denial-of-service attack on a mail box (as in, making the human user trawl through garbage, the mail volume was far from saturating the server itself). What exactly would be a motivation for that I can't tell, except making the life of a small mail server admin even harder than it already is.

> Verify your email address > Welcome to Suga > Reset your password > Three emails they never asked for, from a product they may never have heard of. We were just one of potentially hundreds of sites being hit at the same time.

@homelessdino

Why would you send welcome and reset to some victim that DID NOT verify?

I got subscription bombed from about a dozen .gov sites a while back. Healthcare.gov, Social Security Administration, WTC Health Program, FDA, National Institute of Mental Health, Medicare.gov.

It's very easy for attackers to do this. Putting in effort to solve this for one site, and expecting any impact, is like trying to empty the ocean with a teaspoon.

I stopped offering the trial since I figured it was not useful for a relatively cheap (19 EUR) app that has a 30-day money-back guarantee anyway. (It can also be used for 15 mins without a license, but requires a restart after that.)

Maybe I should just remove it from the sign-up form altogether and use it as a honeypot.

I haven't seen any proof that the big ones (Google, CF) can be easily and automatically bypassed, and would love to learn more if someone has evidence to the contrary.

Now, every mofo just wants a grant to ---- innocent kids in school.

What’s the alternative, though?

What if each service generates a link to a uuid url where all new message will be displayed? The user can rss subscribe to that.

So the user doesn’t receives anything.

As a user, I would prefer no welcome email at all.

Editing to add: almost 100% of these emails came from the same e-commerce product, I'll have to look up which. But every site i got an email from was running the same off the shelf template.

We added a captcha and used a disposable email checking service to get rid of it.

Author, why can you not use your own words?

I am not sure what you meant to say, vs what is LLM garbage I could have prompted myself.