April 5th, 2011, 09:02 AM
Preventing CC Fraud Attempts
We have an ecommerce system that uses Paypal for CC validation. They do a pretty good job stopping fraud attempts but those fraud attempts still cost us money. I'm trying to figure out how I can stop fraud attempts.
The situation right now is that in the past we've had people who will pound our system by constantly trying to place orders with different credit card numbers from different IPs.
So we've put the usual steps in place, if the attempt fails 3 times, the customer is locked out. Adding captchas to new customer forms and login forms.
What else can I do? If these people are using proxies, is there anyway to find out where they are actually located?
April 5th, 2011, 07:10 PM
Are the credit card numbers stolen or just invalid?
Do you think it's the same person doing it?
Do you think it's a bot or a person?
Is there anything in common between the attempts? (User-agent, time of request, sequence of page hits, product ordered, etc.)
How much do the products you sell cost (in general)? Are they digital goods or shipped?
Maybe, maybe not. Depends on whether the proxy operators keep logs, where the proxies are located and how much you want to spend on lawyers. Probably not though.
My guess is that the IPs will trace back to residential ISPs distributed over the world. It sounds like a bot net is using your site to test cards for validity. There's pretty much nothing you can do yourself in terms of going after the operators of the bot net, and going after the people in the bot net will be completely ineffective. What you need to do is disrupt it enough that they stop using your site. Your answers to my above questions might change this assessment though.
April 5th, 2011, 09:44 PM
The credit card numbers are stolen. (A few of them went through)
It's the same person and I only say that because they've created an account with a particular name and I've banned the account and another immediately popped up with the same name but slightly different email.
It's definitely a bot because the order attempts are seconds apart.
It's always the same product being ordered. Always the same customer.
The products we sell range from small replacement parts at $0.08 up to large electronics at $1,000 plus. The orders are for a product at $12.
I've put certain checks in place that will slow them down and hopefully enough that they just give up and try to go somewhere else.
The IPs have traced back to the US and Vietnam. If they trace back to residential ISPs would that mean they're probably not using proxies?
Does this sound like a botnet is behind it?
April 6th, 2011, 01:59 AM
OK, that sounds like what I was guessing. The person is probably testing the stolen cards for validity before selling them.
It's good that it's a bot. It's likely a bot that's customized specifically for your site, or specifically for the software that your site is running (if it's not custom built). That means you should be able to throw it off without too much effort on your part.
If you identify his account again, rather than banning it try more subtle method. If you ban it he knows he's compromised and will just create a new account. Instead, try not giving him any warning and simply program your order processor to not process the order but to just "spin" on the final step of the checkout process (ie: don't sever the connection but also don't return any data either, like an infinite loop in your server side code (except don't do that exactly because it will kill your CPU usage)).
The point of this is to tie up his bot waiting for the request so it can't issue another request. The bot will timeout eventually, but you'll minimize the number of requests that he can run.
This is good, especially if he is using the same account for all of the order attempts. If you identify a single account that fails X times in rapid succession you can add it to a black list of accounts and handle them as described above. If the order is for $12 you can leave X really low since the chance of it being an legitimate order are low.
This is probably your best approach.
If they trace back to a wide variety of different US ISPs then it's almost certainly compromised machines that they're using. In this case, tracking them down yourself is pretty much impossible. If it tracks back to a single US ISP then the person might actually be using their own connection, although I doubt it.
If I were you, the first thing I would do is contact law enforcement and let them know about the problem. I think the FBI might handle credit card fraud, although I'm not certain whether it's within their jurisdiction or not. Even if they don't, they could probably direct you to the proper agency. Given the speed at which law enforcement generally operates on this sort of thing, it's unlikely that contacting them will help you solve your problem. However, you may be able to provide them with very valuable information that will let them track down these people, and in the long run that will help the people whose cards are being stolen (They are probably in far worse financial shape because of this than you). So contacting law enforcement here is strictly a good samaritan type of thing.
Second, implement a better captcha. The person could potentially be using humans to solve the captcha though, so this may or may not work. You want to make sure though that the bot isn't solving them. You could even only implement captchas for $12 orders to avoid annoying your customers. (Implement the captcha for the order process too, not just for registration)
Third, make random source code changes that won't affect a human but will throw off a bot. For example, maybe switch the names of your credit card number and e-mail address fields. A real human doesn't use the names of the fields to figure out where to put data, but a bot does. This will cause the bot to send its e-mail address as the credit card number and the credit card number as the e-mail address; allowing you to identify the bot.
It's also possible to use dynamic form field names instead of static ones. This will force the bot programmer to do a lot more work to send the form.
You could even randomize the order of the elements in the HTML and then use CSS to re-order them into the correct order on the screen. Combining this with random form field names would be a pain in the *** for the bot writer.
One thing to note about this, they decrease your sites accessibility (for the blind) since screen-readers are essentially bots. So you may want to only implement these features for orders matching the bot's characteristics (like for $12).
If you think someone is a bot, you could randomly insert interstitial pages into the checkout workflow. For example, after they submit their credit card number you could randomly display a page asking them to confirm that they are human and requiring them to press a button before processing the payment. The bot writer will then be forced to implement checks and take different paths depending on whether the interstitial page is shown or not.
Basically, your goal is to make it as ****ing annoying as possible for the bot writer. He can adapt to your changes, but if you keep making new changes eventually he will probably give up and move on to someone else's site.
Can you see the times between page requests? Humans read before clicking (well, most of the time!), whereas a bot will be very fast, so maybe check to see how long the last page was displayed, and if it was less than say 5 seconds, ignore the request. This may screw the bot up (it thinks it clicked, nothing happens, and it may not try again expecting the site to load the next page).