One morning I woke up to find 20,000 new fraudulent orders on a WooCommerce site I manage. The vast majority of them were in failed status, but a few had successfully completed. We quickly determined this was a card testing attack, where a fraudster was using an automated system to iterate through a huge amount of stolen credit card numbers to check out on our site and determine which ones were still valid.
The biggest concern with this type of attack is that your credit card processor may stop processing payments from your site altogether due to fraud concerns, which means the business is dead until you can find a new payment processor.
As soon as we noticed the fraud, we alerted our payment processor and let them know we were taking steps to stop the attack and refund the fraudulent orders- which I think was helpful for keeping our account in good status.
Steps for Managing the Attack
There are a number of ways to help prevent an attack like this.
The method suggested by our payment processor was to add a captcha to the account creation page and the checkout page. This makes it much more difficult for a fraudster to use automated tools for card testing. I’ve heard this is very effective and a lot of sites use it, but it wasn’t our first choice as we wanted to avoid any additional friction on checkout for legitimate customers.
Cloudflare is a service that sits in front of a web server and manages incoming requests. We use it primarily as a caching layer and CDN to help improve website performance, but it is also a great defensive layer to block malicious traffic. Their $20/mo Pro Plan is one of the values you can find for an ecommerce business (full disclosure, I have since purchased “NET” stock and fully expect them to raise prices 10x at some point).
Since the attack was ongoing, our first move we made was to block the IP addresses that accounted for the majority of malicious traffic in Cloudflare. It was super clear which IP addresses needed to be blocked because they were sending 1000x more traffic than anything else. (However, it may not always be that clear if an attacker is rotating IP addresses.)
Then next thing we did was “Configure Super Bot Fight Mode”, which does what it sounds like.
We blocked all “Definitely Automated” bad bot traffic, which instantly neutered the rest of attack and. It also blocked some good bots we rely on for third-party services, so when we noticed those starting to fail we added their IPs or User Agents back to an Allow List which permitted all their traffic to go through.
Since the attacks kept flaring up whenever we disabled this Super Both Fight Mode rule, we now just have it on permanently.
Cloudflare Rate Limiting
Cloudflare has rate limiting rules to limit certain types of actions on specific pages. As another step to prevent fraud, we now provide a challenge if a specific IP address attempts to load the account page or the checkout page more than 10 times in a minute (which would be hard for a normal customer to do).
Steps for Cleaning up Fraudulent Orders
Once the attack was blocked, we still had 20k+ failed orders, customer accounts, and subscriptions to deal with. We decided to delete everything except the ~5 orders that had been completed and then refunded (so that we had a record of it).
Since the fraudster only used about 20 IP addresses to create all these orders, we wrote a script that would identify and then delete based on the IP address used. But obviously if you have this issue, the attacker may have rotated IP addresses and you’ll need to use another way to identify the fraud orders.
Deleting 20k orders, subscriptions, accounts and all the associated meta in WooCommerce can take a long time. We wrote a script to do this and basically left it running all day. In case this script might be useful to you, you can find it here.
If you’re running a WooCommerce business, you definitely need to be aware of attacks like this. I highly recommend setting up Cloudflare now so that everything in place in the event you need it and also preemptively setting up some basic fraud prevention rules.
Thanks for the timely write up! We just dealt with this a couple of times, too, and I’m not much of a technical guy. I threw on a reCaptcha plugin, but I had the same friction concerns as you.
We’re already using Cloudflare, so thanks for the directions for making that work better to prevent this sort of thing. Very much appreciated!
Thanks for writing all this up, we just experienced the same thing and defences were lackluster. Now we have 10+ k spam accounts, orders, and subscriptions to clean up.
> It also blocked some good bots we rely on for third-party services, so when we noticed those starting to fail we added their IPs or User Agents back to an Allow List which permitted all their traffic to go through.
CF bot fight page has a disclaimer
“Note: Super Bot Fight Mode cannot be bypassed by other security products. Learn more” pointing to https://support.cloudflare.com/hc/en-us/articles/360035387431#5KX8t3C6SObnoWs5F6YOlU
But you’re saying there’s still an Allow List that modifies Bot Fight behavior?
I believe the IP Access rules are the only thing that bypass the Bot Fight behavior (https://developers.cloudflare.com/waf/tools/ip-access-rules/) so you need to have the IP address or ASN.
However, I am having trouble finding documentation confirming this on Cloudflare now.