We wanted to dedicate a blog post to provide more than 280 characters worth of detail around the recent unrecognized activity and declines.

Some customers may have noticed unauthorized transaction attempts from the following merchants.

Please note, that while the transactions originated from these merchants, we do not believe these merchants are in on the fraud. Rather, we believe that they are being exploited by attackers likely deploying a botnet to circumvent the merchant’s rate limiting.

Descriptor               Phone/Location     Country
==========================================================
WEMOVE.EU                +49306XXX4195      DEU
ST. ROCCOS HOSPICE       +44019XXX7578      GBR
LANTERN INSURANCE NZI    TAKAPUNA           NZL
BETTERPLACE.ORG/GUT.OR   +49307XXX4488      DEU
DONATE                   +44121XXX5830      GBR
NOTTINGHAM MENCAP        +44011XXX0952      GBR

We would like to reiterate that we do not believe these merchants are fraudulent actors and phone numbers have been redacted.

Botnets and Abuse Traffic

We’re no stranger to botnet attacks. On any given day, if you were to tail our system logs, you would see that a large volume of screen space is dedicated to abusive traffic. On most of those days it’s credential stuffing, otherwise known as brute force login attempts. We largely mitigate this by correlating and analyzing traffic at the IP → network → ASN → RIR levels to detect anomalous and abusive traffic. This abusive traffic typically originates from networks in unfriendly jurisdictions, so it’s particularly difficult to prosecute. At other times the network owners themselves are the victims. In recent history, a large credential stuffing attack against our system came from tens of thousands of IPs, all from one of the more popular South American telecom carriers.

A New Kind of Botnet Attack

In recent weeks, we’ve noticed an uptick in a new kind of attack—botnets are directing their attention at merchants with weak rate limiting safeguards and are attempting card number enumeration attacks within our range of card numbers. (It is worth noting that we don’t have concrete evidence that the attackers have been utilizing a botnet to perpetrate this attack, but given the rate of attempts on our system, our reasonable conclusion is that they are.) In this attack, fraudsters employ automated trial-and-error authorization attempts on card numbers at unwitting merchants. The attack roughly follows this pattern:

1. The attacker attempts a low dollar authorization with a random, valid-looking card number at a merchant identified to have unsophisticated rate limiting. The authorization is attempted without including a “card verification value” (CVV, CVC2) or expiry. Though it may seem counterintuitive, this is a valid authorization request and, unfortunately, many utility companies run authorizations without this card meta data included.
2. If the attacker receives a decline code for “invalid card number,” they repeat step (1) with a new card number. If the attacker receives any other response code, they know this is likely an actively provisioned card number and can continue.
3. Once an active card is identified, the attacker will attempt further authorizations with the same card number, continuing to omit the CVC2 while enumerating possible expiry dates. Most payment cards expire within four to six years from issuance, so it doesn’t take many attempts to find the card’s expiry.
4. Now that the attacker has a valid card number and expiry, they can move on to a new merchant. The attacker selects this new merchant based on a different set of criteria—instead of a merchant with permissive rate limiting, the attacker chooses a merchant that will allow for cashing out (perhaps a peer-to-peer payment network or a merchant account they, or a known associate, controls).
5. Once the “cashout” merchant has been identified, the attacker runs a larger authorization attempt with the valid card number and expiry, but no CVC2, hoping that it will be authorized. (Running an authorization without a CVC2 is a very common authorization request type; any merchant that utilizes recurring billing at times runs authorizations without a CVC2.)

Can an attacker really brute force card numbers?

A common question is, “a card number is 16 digits which means a huge number of possible combinations... how can an attacker actually guess a valid number?” Interestingly, the probabilities of a “hit” are higher than one might initially expect.

Anatomy of a card number

Visa and Mastercard numbers are 16 digits in length, the first 6 digits of which are the Issuer Identifier Number (IIN, also known as a BIN). When a merchant runs an authorization to one of our cards, the payment card network uses the card number’s IIN to route that authorization request over a private fiber circuit to our authorization servers.

Of the remaining 10 digits, the final digit is a simple checksum, a holdover from the days when physical cards were run over a magnetic head, and exists to ensure that the magnetic stripe was properly read.

Case Study

Accounting for the six digits of the IIN and the one digit checksum, we are left with nine digits per IIN to play with, which encompasses an address space of 10^9 (1 billion) possible combinations.

Consider 1 million customers with 10 cards each. (In practice, it’s not unusual for active Privacy customers to have a few dozen cards, one for each merchant relationship, and it’s not uncommon for business customers federating access to their corporate funds with Privacy to have orders of magnitude more cards.) With 10 million provisioned cards, the IIN’s address space is already 1% saturated, meaning that, after just 100 random guesses, there’s a 63% chance you have found a provisioned card number, and after 500 random guesses, it’s 99%. Unfortunately, it’s low-cost (bordering on free) for an attacker to make an authorization request, which makes an attack like this more worthwhile than one might expect.

The Good News

Because Privacy Cards are designed only to accept transactions from merchants they have been previously used with, and can deactivate after the transaction lifecycle is completed, the biggest customer effect that these attacks have had has been the annoying transaction decline emails. In the rare event that a fraudulent transaction gets through, no harm will come to the customer. All of the cards we issue are covered by our unauthorized transaction policy.

While an overwhelming majority of these fraudulent authorization attempts were made on invalid card numbers, the attackers did succeed in finding the small percentage that are provisioned cards. Below is the breakdown of transaction attempts made on provisioned cards, grouped by response type during the last 7 days:

Authorization response                 Percentage
=================================================
declined card closed                      48.15 %
declined unauthorized merchant            40.02 %
declined inactive account                  5.34 %
declined card paused                       3.63 %
declined invalid card details              2.48 %
declined user set transaction limit        0.33 %
approved*                                  0.04 %

* A small number of customers experienced unauthorized approvals. Those customers have been contacted and made whole.

What We’ve Done

We’ve filed a fraud report with Visa, notifying them of the unusual activity, so they can pass the information along to the merchants at which these attempts are originating. Unfortunately, attacks like this are dynamic and always evolving. When a merchant becomes aware of this and tightens their security, the attackers move on to another merchant to continue their exploits. While this is inherently a game of Whac-A-Mole, we play to win. We will continue to block transactions and notify merchants whenever we observe anomalous activity.

We’ve implemented an outlier classifier and placed it in the authorization stream to identify and decline authorization requests from merchants that appear to be enumerating PANs. Further, we now flag all authorization requests that are somewhere between “definitely PAN enumeration” and “totally normal” for human review. This way, no funds are drawn before someone has verified the validity of the transaction.

Interested in tackling problems like this and helping us make payments safer and smoother? We’re hiring!