A few days ago a client complained their Magento website was suffering from a bot attack in the checkout with the credit card payment. They received thousands and thousands (I mean, thousands, like more than 30 thousand) of failed transaction emails in their email inbox. They immediately asked for our help to investigate and apply a fix, even an emergency one, so that their business wouldn’t have much impact because of it.

Well, we started the investigation and the first thing done was to identify all the IPs from the attacker and block them at the server level so the requests wouldn’t reach to the application level and slow down their website completely.

It was done like below:

$ grep POST /var/log/nginx/www.store.com-access.log | awk {' print $1 '} | sort | uniq -c | sort -k1 -nr | head
 158458 89.117.9.82
  71066 149.18.62.168
  29478 20.2.87.95
  23940 158.62.50.127
   4337 143.44.165.26
   1124 49.145.118.199
    236 173.219.176.86
     93 15.235.118.223
     65 149.100.151.50
     54 52.5.52.101

So, there were a lot of requests like the following ones:

89.117.9.82 - - [02/Oct/2023:09:04:37 -0400] "POST /rest/V1/guest-carts/dHLtSli7L3Kr26cI1XorZqByVKcMxEAN/payment-information HTTP/1.1" 400 111 2.762 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 38.0; Win64; x64) AppleWebKit/525.45 (KHTML, like Gecko) Chrome/82.0.5168.677 Safari/789.60" "-"
89.117.9.82 - - [02/Oct/2023:09:04:38 -0400] "POST /rest/V1/guest-carts/OJpRIgFg3HEe4PTo7lj06sXGyTrMfCYc/estimate-shipping-methods HTTP/1.1" 200 12599 2.488 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 31.0; Win64; x64) AppleWebKit/193.54 (KHTML, like Gecko) Chrome/88.0.4223.409 Safari/495.32" "-"
89.117.9.82 - - [02/Oct/2023:09:04:38 -0400] "POST /rest/V1/guest-carts/kfDmRjK8DLsARiryYNbCHYcgDA6qpQvi/shipping-information HTTP/1.1" 200 2174 1.777 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 95.0; Win64; x64) AppleWebKit/855.57 (KHTML, like Gecko) Chrome/20.0.2563.308 Safari/777.71" "-"
89.117.9.82 - - [02/Oct/2023:09:04:38 -0400] "POST /rest/V1/guest-carts/IBvX3FFKABYlEXVuQTBGanx3vt3gXHqK/shipping-information HTTP/1.1" 200 2264 2.549 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 21.0; Win64; x64) AppleWebKit/181.32 (KHTML, like Gecko) Chrome/54.0.4629.697 Safari/233.79" "-"
89.117.9.82 - - [02/Oct/2023:09:04:38 -0400] "POST /rest/V1/guest-carts/kfDmRjK8DLsARiryYNbCHYcgDA6qpQvi/shipping-information HTTP/1.1" 200 2174 0.326 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 95.0; Win64; x64) AppleWebKit/855.57 (KHTML, like Gecko) Chrome/20.0.2563.308 Safari/777.71" "-"
89.117.9.82 - - [02/Oct/2023:09:04:38 -0400] "POST /rest/V1/guest-carts/IBvX3FFKABYlEXVuQTBGanx3vt3gXHqK/billing-validate-address HTTP/1.1" 404 47 0.071 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 61.0; Win64; x64) AppleWebKit/246.62 (KHTML, like Gecko) Chrome/55.0.4106.805 Safari/435.14" "-"
89.117.9.82 - - [02/Oct/2023:09:04:39 -0400] "POST /rest/V1/guest-carts/kfDmRjK8DLsARiryYNbCHYcgDA6qpQvi/billing-validate-address HTTP/1.1" 404 47 0.075 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 93.0; Win64; x64) AppleWebKit/902.33 (KHTML, like Gecko) Chrome/50.0.9297.407 Safari/399.63" "-"
89.117.9.82 - - [02/Oct/2023:09:04:40 -0400] "POST /rest/V1/guest-carts/OJpRIgFg3HEe4PTo7lj06sXGyTrMfCYc/shipping-information HTTP/1.1" 200 2279 1.782 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 22.0; Win64; x64) AppleWebKit/476.31 (KHTML, like Gecko) Chrome/66.0.7130.369 Safari/260.26" "-"
89.117.9.82 - - [02/Oct/2023:09:04:40 -0400] "POST /rest/V1/guest-carts/IBvX3FFKABYlEXVuQTBGanx3vt3gXHqK/payment-information HTTP/1.1" 400 111 1.705 "https://www.store.com/checkout/" "Mozilla/5.0 (Windows NT 41.0; Win64; x64) AppleWebKit/529.35 (KHTML, like Gecko) Chrome/98.0.2874.553 Safari/268.66" "-"

And each of these IPs made a huge number of requests to the website:

$ grep 89.117.9.82 /var/log/nginx/www.store.com-access.log | grep payment-information | wc -l
6088

$ grep 149.18.62.168 /var/log/nginx/www.store.com-access.log | grep payment-information | wc -l
23810

$ grep 20.2.87.95 /var/log/nginx/www.store.com-access.log | grep payment-information | wc -l
932

$ grep 158.62.50.127 /var/log/nginx/www.store.com-access.log | grep payment-information | wc -l
7909

Alright, the emergency solution was in place and the attacks stopped for some time. We could breathe again and look for a permanent solution now.

I started with the simplest things possible, like checking the Magento version, if it’s a Commerce or Open Source edition, if the Google ReCaptchas were enabled, and… Wait! When I checked the Google ReCaptcha all of them were deactivated like it was a newborn website right out of the oven. No wonder the attackers were playing around without problems.

For those who are asking what kind of attacks a hacker can make to your site in this case, the most common one is when they have a list of credit cards they purchased somewhere in the dark web or stole from somewhere and they want to filter the valid and the invalid ones and validate the authenticity of the credit cards. This is called Carding Attacks. One of the biggest problems, when this happens, is that the Payment Gateway, like Braintree, PayPal, and others, usually puts the client’s website on a blacklist, and the website is blocked from processing any other order by using the credit card payment method, even a valid customer purchase. This may have a huge negative impact on the client’s revenue, in the end.

I suppose you don’t want to take this risk, right? Alright, let’s talk about why it’s so important to enable a simple solution called Google reCaptcha, which is bundled in Magento 2 already.

Enabling Google reCaptcha in Magento 2 is a crucial security measure that offers several benefits. Here are ten compelling reasons why any Magento 2-based e-commerce platform should have Google reCaptcha enabled on pages with sensitive information, especially the checkout page:

Prevents Automated Bot Attack

Google reCaptcha effectively distinguishes between human users and automated bots. By implementing it on the checkout page, you mitigate the risk of fraudulent activities driven by bots, such as account creation spam, inventory hoarding, and payment fraud attempts.

Reduces Fake Account Creation

Bots often attempt to create fake accounts for various malicious purposes, such as spamming, scamming, or even launching distributed attacks. reCaptcha acts as a strong deterrent to such attempts.

Defends Against Credentials Stuffing Attacks

In a credential-stuffing attack, attackers use previously stolen usernames and passwords to gain unauthorized access. reCaptcha adds an extra layer of protection by challenging users with a CAPTCHA, even if their credentials are correct.

Shields Against Brute Force Attacks

Brute force attacks involve systematically attempting various combinations of usernames and passwords. Implementing reCaptcha significantly raises the bar for attackers, as they now need to bypass both the reCaptcha challenge and the login credentials.

Safeguards Against Carding Attacks

Carding attacks involve using stolen credit card information to make small purchases in order to validate the card’s authenticity. reCaptcha helps to detect and prevent these fraudulent transactions.

Enhances Payment Security

The checkout page is one of the most critical areas of an e-commerce site. Adding reCaptcha here ensures that only legitimate users can complete the checkout process, minimizing the risk of fraudulent transactions.

Improves SEO and Ranking

Google considers website security and user experience as important factors in search rankings. Implementing reCaptcha demonstrates a commitment to user safety, potentially improving your site’s SEO and ranking in search results. Surprised by this one?

Builds Trust with Customers

Displaying reCaptcha on sensitive pages reassures customers that your e-commerce platform takes security seriously. This builds trust and confidence in your brand, leading to increased customer loyalty and repeat business.

Compliance with Industry Regulations

Many industries and regions have specific regulations governing online security and data protection. Implementing reCaptcha helps ensure compliance with these regulations, reducing legal and financial risks.

Minimizes Chargebacks

Chargebacks can be costly and damaging to a business’s reputation. By preventing fraudulent transactions through reCaptcha, you reduce the likelihood of chargebacks, ultimately saving time, money, and resources.

How to Create Google reCaptcha Credentials

To create Google reCaptcha credentials, you’ll first need to have a Google Account and be logged in to it. Then you can go to the following website:

https://www.google.com/recaptcha/admin/create

You’ll see the following page:

You basically need to:

1. Give it a Label, a name that identifies what the captcha credentials are for;
2. Select between either a Score based or a challenge type; and
3. Add the domains where the captchas will be set up.

After clicking on the SUBMIT button you’ll see your credentials.

With your keys on hand, it’s time to set up the Google reCaptcha on Magento Admin.

How to Setup Google ReCaptcha in Magento 2

1. Access the admin panel;
2. Navigate to STORES > Settings > Configuration > SECURITY > Google reCAPTCHA Storefront;
3. Open the reCAPTCHA v3 Invisible group;
4. And fill out the form accordingly.

Now, expand the Storefront group and select the option reCAPTCHA v3 Invisible for the pages you want to activate it.

Now you only need to save the configuration and clear the caches. You’ll see the reCaptcha badge on the pages you selected.

Keep in mind that making your store secure for your customers has a lot of benefits for your business, so don’t take this unnecessary risk.

I hope this blog post helps you.

-Tiago