Well written piece on an attack vector I'd never thought too hard about before. Thanks for elaborating on why sending an email or two to a random person helps an attacker achieve their goal. A lot of similar articles skip over details like that.
> If a bot creates an account with someone else’s email, the victim gets one email, if they ignore it that’s the end of it. The welcome email and everything after it only fires once the user verifies.
As a user, I would prefer no welcome email at all.
It's a problem, but I really dislike the solution. Putting a website with known security issues behind Cloudflare's Turnstile is comparable to enforcing code signing—works until it doesn't, and in the meantime, helps centralize power around a single legal entitiy while pissing legitimate users off.
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...
Since they updated the flow to only ever push 1 email to unverified users, I would say that's as patched as it can realistically be before you bring in the captchas.
I had a similar issue and evaluated alternatives. Sadly, there were none that did the job well enough.
How do you suggest to implement bot prevention that works reliably? Because at this point in time, LLMs are better at solving CAPTCHAs than humans are.
I fully agree with your comment. Wouldn't it be possible to just put off sending welcome emails until the user actually engaged with the product in some way? And if an account wigh no engagement persists for more than say three months just delete the account again under the premise of 'eroneousely created'?
I had my email stolen in such an attack, i still get random "you abandoned your cart!" Emails now and then, but luckily (?) they got my credit card at the same time and i cancelled it within minutes. So it's a little annoyance, but it doesn't really make sense to me that the flood works. At least not with American credit cards that are routinely flagging my own trips to microcenter lol
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.
I actually have no idea. I looked up one of the emails in my trash and it doesn't have any "built with" kind of thing or anything. So I can't actually tell what platform they're using, but they're definitely all the same. Here's one of the retailers in question
I absolutely refuse to use BigTech gatekeepers or useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by running names through a simple LLM filter - if the name is gibberish like Px2846skxojw just block the signup. Worked surprisingly well. Of course this is easy to get around if the bot knows what you’re doing. But bots look for easy targets, as long as there are enough vibe coded crap targets on the internet they’re not going to bother with circumventing a carefully designed app.
> useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by (…). Of course this is easy to get around if the bot knows what you’re doing
So, by your own admission, your solution doesn’t get around the “sufficiently advanced bot” problem.
I was attacked in this way a couple of months back. I use a different email address for each account (of the pattern product@example.com), and use a separate address for Git commits (like git@example.com). It was this second one that was attacked and I ended up with some 500 emails within 12 hours. Fortunately, since I don't expect anyone to actually email me on the Git address, I just put up a filter to send them all to a separate folder to go over at my leisure.
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.
Recently we suffered a different kind of subscription bombing: a hacker using our 'change credit card' form to 'clean' a list of thousands credit cards to see which ones would go through and approve transactions.
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.
This is one of those levels of monitoring that only gets put in place after such an event. Eg whole subsystem analysis - the change card feature being used 1000s of times (well, proportional to scale) in 7 hours is a massive red flag
Well, what you can do is notify the card issuer about those cards that went through, so they can mark them as stolen. That surely will make the hacker really happy, and discourage them of doing it again :)
We solved this by introducing a silent block. If the system notices unusual behavior (too many payment attempts per user, for example), it no longer sends the payment attempt to the provider. Instead, it idles for a second or two and then just fails with a generic “payment declined.” Most attackers don’t notice they’re being blocked and just assume all credit cards are bad.
Being used to validate stolen card numbers has long been a problem; we've had to put in a number of defenses to fight our way off whatever list of "easy sites" these folks maintain. I hadn't thought about the "change card" path though...another bit of time spent away from what our business is really supposed to be doing...
We had this happen on one of our sign up forms. I added a crappy open source image captcha and it went away. I guess whichever attacker was using us wasn't that motivated!
Report all received emails as spam, add a filter to get rid of the @domain.com emails, and probably add the entire service to the blacklist so it doesn't happen again. Probably get rid of any paid account on that service one might have laying around.
If the email is targeted at a domain using mail servers from any major email provider (Gmail, Outlook), the user will probably find most emails into their spam folder anyway and the sending domain will get added to the spam list automatically. Especially if the attack hits multiple users on the same email service.
One thing I have never understood in this current age is how in the world so many companies, including ones that handle confidential data like banks, don’t require a user to verify their email address after it’s entered. I have an unfortunately very generic email address that’s easy to mistype, and I am almost every day receiving order receipts for expensive vacation hotels, bank transfer or wire transfer confirmations, a very long list of things that I should not be receiving simply because the companies sending those emails never had the user verify if they entered the right email address. They are legitimate emails, they are often addressed to someone with the same first name as me but a different last name, so that person simply typed the wrong email address accidentally.
It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.
This happened to me several years ago. I got signed up to probably 700 newsletters overnight. In the middle of all of the sign ups there was activity on my airbnb account where my notification settings were changed. when i checked my airbnb i noticed that someone had created a fake listing under my account and disabled booking notifications for it. a real multi-layer scam where the hacker would be making money off a fake listing on someone else's account who would probably never even realize it.
I work the email security company xorlab[0], where my colleagues and I did a thorough analysis of real subscription/email bombing waves that we saw at our customers[1].
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.
> that meant each victim received three emails from us in under a minute:
> 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?
We experienced a similar thing; Thousands of new accounts were being created over a short period, but it was Amazon SES sending us a warning about complaint numbers that woke us up to it.
We added a captcha and used a disposable email checking service to get rid of it.
> The goal [...] to flood the victim’s inbox with so much noise that they can’t find the emails that actually matter.
> 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.
The irony is that the services most vulnerable to this are the ones that collect the most email/data in the first place. Minimal data collection is the best mitigation.
Interesting, until it turned into an ad for Cloudflare, it spreads like plague on the internet, slowing everyday down, forcing JS and trying to pull every single datapoint from your browser. Is this really the _only_ solution?
Could ask new users to send an email on a generated temp adress before sending the confirm e-mail.
I do think e-mail should be not only opt-in, but also optional!
69 comments
[ 2.5 ms ] story [ 77.4 ms ] threadAs a user, I would prefer no welcome email at all.
What I find annoying is services that only send the welcome email once, and don't let you resend it if you never receive it.
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...
How do you suggest to implement bot prevention that works reliably? Because at this point in time, LLMs are better at solving CAPTCHAs than humans are.
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.
https://utopiagoods.com/
My conclusion is to move from WordPress software as fast as possible, every WordPress site I manage gets bombarded by bots.
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.
So, by your own admission, your solution doesn’t get around the “sufficiently advanced bot” problem.
I hope "LLM thinks your name is gibberish" won't become the new "your name can't include invalid characters".
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.
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.
This is one of those levels of monitoring that only gets put in place after such an event. Eg whole subsystem analysis - the change card feature being used 1000s of times (well, proportional to scale) in 7 hours is a massive red flag
JS can be reversed, you clearly see what data points they use for detection. Anything can be spoofed and it will look like human behavior.
And if everything fails, you outsource it to AI - Always Indian :D
If the email is targeted at a domain using mail servers from any major email provider (Gmail, Outlook), the user will probably find most emails into their spam folder anyway and the sending domain will get added to the spam list automatically. Especially if the attack hits multiple users on the same email service.
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...
> 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?
We added a captcha and used a disposable email checking service to get rid of it.
> 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.
Now, every mofo just wants a grant to ---- innocent kids in school.