Recent Posts

Recent Blog Posts

The PhishLabs Blog

Cybercriminals abuse charities to verify stolen credit card data

Posted by Don Jackson, Director of Threat Intelligence on Nov 21, '14
Find me on:

It should come as no surprise that cybercriminals have yet again displayed superior moral character with a scheme exploiting websites of non-profit organizations to verify stolen card data. PhishLabs’ R.A.I.D (Research, Analysis, and Intelligence Division) has uncovered an underground service that allows cybercriminals to use an interactive chat bot to automate the verification of stolen payment card data. The bot is a script programmed to login to an online chat channel and monitor it for messages containing data such as credit card numbers, cardholder names, and expiration dates using a special input syntax. Miscreants are purposefully targeting websites of non-profits with this service to verify stolen credit card data.

Bot design and implementation

When cybercriminals join the online channel and "chats," the bot uses the data provided (cardholder name and information) to input and run transactions against the websites of charities and other non-profits in order to verify that the card data is correct and the account is active. The bot then reports the results and any transaction details back the crook.

The bot interacts as a user on an IRC (Internet Relay Chat) channel. Functions like card verification are handled through private messages between a moderator, the criminal service's customer, and the bot's own "user" ID on the same chat channel. These messages contain bot commands formatted using a specific syntax recognized by the bot. Using the private message feature allows the service's users to chat openly with each other but keep messages that contain things like valuable card data out of the hands of the other criminals on the channel.

The bot itself is a program implemented in the perl programming language. Although based on a design for IRC interactions that dates back many years, this bot uses specific modules and code customized for cybercrime purposes first seen in 2011. This particular strain of criminal tailored code is known for its use of Portuguese for comments and variable names.

The source code to those bots is available, but compared to those older bots that were coded for a single main purpose, the bot used in this case is larger and more complex, handling many different functions that cybercriminals may find useful. Indeed, in addition to automated card verification, this bot also includes modules for tasks such as:

  • Checking tracking numbers on packages, for example, used by the channel members to track items purchased using stolen cards through a "reshipper" network
  • Address and ZIP code verification for cardholder identity data

However, card verification seems to be the primary use, and that's the main draw for the service's customers. See Figure 1 for a snippet of code showing the card verification data.


Figure 1 - Bot source code snippet showing card data approval messages

Access to the bot service

This particular service has been advertised on certain closed underground forums that vet membership applicants in various ways rather than allowing members from the public to enroll themselves. The service has become so successful, however, that virtually all new business is acquired through word-of-mouth.

Once added by the service's administrator, the customer will receive information on how to authenticate to the service via chat. The channel is protected by a watchdog bot that watches for and bans or "kicks" any users it cannot authenticate. 

Criminals must then earn or purchase "credits" to continue to use the service. Credits can be earned in a variety of ways: 

  • Purchased with funds via wire or cash transfer, with virtual online currencies such as WebMoney, or with Bitcoin or a number of similar cryptocurrencies
  • In barter for other services or referrals to other services that help support the operators' criminal enterprise.
  • In exchange for helpful information such as reports of "rippers" or investigations.
  • As payment for completion of a specific task or mission, such as voting or vouching for someone's forums access or the delivery of the source code to a particular malware builder kit.
  • As a finder's fee for referring new members.
  • In exchange for stolen data, including account credentials for various online services and, of course, payment card data.

In some cases, customers of the service will exchange part of the stolen card data they've logged for credits. These are separated out and sent to the admin who may request certain card types from certain card issuers (based on the BIN/IIN part of the card number) or from certain geographic regions. Once the admin uses his own bot to verify the card data, the user is given a certain number of credits which can then be used to verify the customer's remaining stolen cards. 


Figure 2 - Sample of chat log showing public and private (bot) messages 

The bot does limit use of the service based on more than just credits. It also enforces limits on the total number of cards verified by a user in a given time period and requires a mandatory "cool down" time between each card verification check. These are done to limit transaction velocity and remain below any fraud detection system's radar. The bot also cycles through a list of web forms at various legitimate domains to protect against performing too many checks too close together against any one particular merchant account.

Why Charities and Non-Profits? 

Assuming nicknames as customary, PhishLabs R.A.I.D. initiated conversations with two different channel moderators, and those responsible for running the service confirmed the following: 

  • The carders, those stealing and trading in stolen card data, do not have to worry about managing their own compromised or clandestine merchant accounts.
  • The operators of charity and non-profit websites put as few obstacles in the way of making a donation as possible which makes it relatively easy for bots to run automated transactions.
  • These types of websites seem to have fraud detection profiles that result in a relatively low number of declined transactions for valid card data. The ability to verify small amounts from many different types of cards issued in many different countries seems to work more reliably for the criminals than, for example, retailer websites.

One moderator offered the absurd suggestion that letting the charities keep the funds used to verify the cards somehow compensated for damage done to the actual cardholders. Another moderator suggested that cardholders would be less inclined to report payments as fraudulent since they were sent to a charity or non-profit. However, once flagged for other fraudulent activity, the organizations behind the abused websites would suffer loss from charge backs and the time and effort it would take to identify related activity.

Identifying related fraudulent activity 

It essential to spot the verification activity early to prevent additional losses and larger scale fraud later. The hallmark of this activity is the small, random amounts used in the verification checks. Amounts in the range of USD $1.00 to $5.00 are randomly chosen, so they will usually have some number of cents in the amount. This is done in an effort to thwart fraud detection systems that would flag consistent amounts from so many sources in such a short period of time; however, many people make smaller online donations in whole dollar amounts. It may seem odd to see a payment to a charity or non-profit in some partial dollar amount such as $1.09 or $4.86 on an e-receipt, conformation or account statement.

Operators of websites that may have been targets for abuse can also look for the same pattern in the amounts paid, especially in bursts of transactions each separated by some short period of time usually in the range of a few seconds to a couple of minutes. Additionally, website operators can correlate the IP addresses with payments and donations. Confidence that one has spotted this type of activity is raised if the geolocation look up on the IP address is ether of the following, especially when taken together: 

  • Vastly different than the cardholder's billing address
  • Associated with many of these small transactions from many different cardholders

Preventing abuse of online payment/donation forms 

To prevent these types of losses and abuse, web forms that accept payment card information must be protected against automated submission of card data like that performed by this criminal service's bot. Some tactics include: 

  • Randomized URLs
  • Randomized form field names or token values
  • Using hidden fields
  • Checking parameter order in HTTP POST requests to form action targets
  • HTTP Referer header checks or other session state information to better determine of the request came from someone actually visiting the website instead of directly from some criminal's server
  • Require visitors create an account, even a simple one that just provides a "supporter ID" that must be re-entered with payment
  • Require an email address and send a payment verification request before payment can be processed
  • CAPTCHAs or other similar anti-bot measures 

All of these will require some changes to the website and some may introduce an additional step or two in the donation process. Most changes are relatively minor compared to retailer websites and on par with was a visitor to a blog must do to post a comment. 

Operators of this criminal service's maintain a list of unprotected payment submission web pages and configure the bot for how to run transactions against each one. Those targets that have implemented one or more of these countermeasures have been pruned from the bot configuration. 

Follow our blog for the latest cyber security news.

Topics: Fraud

What's this all about?

The PhishLabs Blog is where we share our insights and thoughts on cybercrime and online fraud.

Recent Posts

Subscribe to Email Updates

Posts by Topic

see all