Attacked by “card testing” – “origin unknown”

I have had the same issue, and I brought it up to our account executive at PayPal because i dont have this issue on sites I manage using other payment gateways. Investigating the logs I found this:

The bots are making use of the open REST API built into WooCommerce/WordPress to submit these orders and otherwise bypass a lot of built in checks that are part of the standard checkout process.

It starts with the bot hitting wp-json/wc/store/products in WooCommerce with filters that sort and list your cheapest products first, making it easier for them to test stolen cards. Then they start to submit POST requests to the REST API endpoint to add to cart, checkout, create order, push payment to PayPal and even seen them find a way to forcibly bypass Fraud filters within PayPal and get the payment to go through even when the filters are set to block AVS N responses (sent this to our PP rep also).

So we looked at the official wordpress documentation on restricting the REST API (https://developer.www.ads-software.com/rest-api/frequently-asked-questions/#can-i-disable-the-rest-api)
While they do not recommend shutting it down completely as it can break 3rd party plugins and functionality in the admin panel, I decided to take their code for “Require Authentication for All Requests” and modified it to only require the user be logged in when hitting that initial wp-json/wc/store/products URL with the in stock and sorting filters.

I will monitor and let you know if this stops it without breaking anything. I cannot promise this use-case will work for all sites and setups. We modified the logic from the URL above with this URL check:

$api_url = $_SERVER[‘REQUEST_URI’]; //Added this to get the url the user is trying to hit

if ( ! is_user_logged_in() && str_contains($api_url,”/wp-json/wc/store/products”)) {? ? ?

Same issue happening to our store. This method in the link below is currently working for us, but I would hope there will be a more permanent solution by the plugin developers.

https://www.denialdesign.co.uk/blocking-card-testing-attacks-in-woocommerce/

• This reply was modified 2 months, 3 weeks ago by rpikus.

12ish hours in and it has fully stopped the bot orders and we have not seen any issues with other functionality and real orders coming in without issue. I am still waiting to hear back from PayPal about how they are using the REST API unauthenticated to bypass fraud filters on the payment gateway side because that feels like a serious vulnerability that needs to be addressed.

Thanks for the updates … I’ve just added the function from denialdesign to give that one a go.
Have heard nothing back from my ticket at Woo….

Glad the code snippet is working for you guys too. Hopefully PayPal or Woo can provide a better fix shortly.

@denialdesign – thank you for sharing your solution!

Hello @sonic1243

We are aware of the recent card testing attacks from the last two weeks. After reviewing the situation briefly, the key to resolving this problem lies in obtaining complete logs from users who are encountering these issues. This is crucial for us understanding the full scope and helping with prevention.

How to share a logs with us:

Please note that logs are only generated if “Logging” is enabled in your PayPal Payments plugin settings. You can enable this feature under the “Connection” tab in the plugin settings. Once enabled, every transaction will generate a log entry. If logging was not enabled previously, we won’t have records of past transactions. In that case, we will need to wait for new orders to generate logs.

To retrieve the logs, go to WooCommerce > Status > Logs and select the most recent “woocommerce-paypal-payments” file that matches the date of the fraud orders.

You can upload these logs to PrivateBin and share the link with us for further investigation. If you do not wish to share this information publicly, please feel free to contact us directly, and we will assist you further. You can also open a support ticket with our service desk: Request Support. Be sure to include the URL of this thread in your ticket.

As for the snippet from Denial Design, I tested it and consulted with developers. It doesn’t seem to affect the basic functionality of the plugin. While we can support this snippet if it helps, we want to be clear that it disables a core WooCommerce functionality, not a PayPal Payments-specific one.

Please keep in mind that these bot orders are essentially using the API, and as of now, there’s no way to distinguish them from legitimate orders.

We also suggest that all affected users contact us privately, along with their logs for analysis.

Let us know how you’d like to proceed, and we’re here to assist further.

Kind Regards,

Krystian

Here’s the PayPal logs from the last day one of my clients was attacked.

https://privatebin.syde.com/?d2c7e8f987621ba1#GvfR9sybymFTCAT3D4W3K4tApwFBUznmNueypFqPWWHX

Thanks.. I tried wc_endpoint_v1 which did not work, had 40 failed orders over the day..
Am trying the wc_endpoint function as well now.
I didn’t have logging for the Paypal plugin, but I have enabled this now.

Hello @denialdesign

Thank you for sharing the logs.

From the logs, it’s quite clear that all fraud attempts were successfully handled by PayPal and the card provider’s security systems.

Additionally, it looks like you have the SCA_WHEN_REQUIRED setting configured. If you want to be as strict as possible in preventing fraud, you should consider setting it to always trigger 3D Secure. Also, I’m not seeing any evidence of reCaptcha on the site, which in theory could also help reduce automated order attempts.

Let me know if you need any further assistance.

Kind Regards,

Krystian

Thanks @inpsydekrystian I will check the settings.

reCAPTCHA does not stop the attacks through the API. I have tested it on a different site.

I have logs that show the fraud orders bypassing PayPal Fraud filters. After hitting the JSON of the catalog and adding to cart via API it directly queries the PayPal endpoints for getting a token/client id, creating an order, and forcing an approval. See below

“POST /?wc-ajax=ppc-data-client-id HTTP/1.0” 200 1061?XXXXX?“Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML like Gecko) CriOS/120.0.6099.119 Mobile/15E148 Safari/604.1”

“POST /?wc-ajax=ppc-create-order HTTP/1.0” 200 700?XXXXX?“Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML like Gecko) CriOS/120.0.6099.119 Mobile/15E148 Safari/604.1”

“POST /?wc-ajax=ppc-approve-order HTTP/1.0” 200 621?XXXXX?“Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML like Gecko) CriOS/120.0.6099.119 Mobile/15E148 Safari/604.1”

“POST /wp-json/wc/store/checkout HTTP/1.0” 200 3155 “

Then when I go into woocommerce, I see the order approved with an AVS response of N and CVV response of N even though we have the filters enabled to reject any CVV or AVS response of N. I sent this all to our Rep yesterday to open a ticket.

Hello @denialdesign

That’s true.

Regarding this case – yes, you can block orders from being created via the API to reduce these attacks, but this isn’t a feature we can manage at the plugin level, as it’s provided by WooCommerce itself.

As long as the fraudulent orders are being declined, the system is functioning as expected. I understand this might not be an ideal situation, but from the plugin’s perspective, there isn’t much we can do about declined fraud attempts, as this is the intended behavior.

We have seen cases where similar attempts led to orders being processed, which is a significant concern for us, and we’re working on a patch to address that (package is in acceptance tests). However, that issue doesn’t apply to the situation you’ve experience right now.

Hello @rprentice84

Thank you, I have just forwarded this to the developers.

Kind regards,
Krystian

Hello @rprentice84

It seems there is a misunderstanding regarding the AVS and CVV responses. These notes show “Y” or “N” based on whether PayPal returned an “M” status for the address, postal code, or CVV match.

You can find more details in the PayPal documentation here: PayPal Card Decline Errors.

To clarify, an “N” in the order notes does not mean PayPal explicitly returned “N.” Instead, it means PayPal returned a response that is not “M.”

Kind regards,
Krystian

@inpsydekrystian There is no misunderstanding. I can confirm when i log into our merchant account with PayPal the AVS response code listed is N, not M. And we confirmed with the chargebacks received the address provided on the orders was not a match.