Gift card draining bots: the balance check that gives the game away

The first sign of a draining run is not an empty card. It is a Tuesday afternoon where balance inquiries triple and gift card sales do not move. Somebody is testing which stolen numbers still hold value, and your balance check page is doing the testing for free.

How draining actually works, step by step

Card numbers and PINs reach attackers two ways. In stores, crews tamper with cards on the rack, recording numbers and PINs before a buyer loads them, a scheme the FBI and state attorneys general have warned about repeatedly. Online, numbers leak from breaches and phishing. Either way, the attacker holds a list and needs one answer per card: is there money on this, and how much.

That answer comes from your balance checker. A bot works the list through the checker, sometimes through a phone line as well, and flags the loaded cards. Those get drained in a burst, often into resale channels or purchases of goods that convert to cash, frequently before the real owner tries to spend. Krebs on Security has traced draining crews moving balances within hours of a card being loaded at a register.

Why unlimited balance checks are the weak point

Most balance pages were built for a shopper holding one card. No sign in, no limit, instant answer. That design hands an automated tester exactly what it needs: unlimited, anonymous, machine readable answers. Each individual check looks harmless, which is why the defence has to be built on the pattern, not the single request.

The useful signals are ratios, not events. Inquiries per session, inquiries per account, the share of inquiries for cards never sold through your own channels, and the gap between inquiries and redemptions. A human redeems or saves the card. A tester moves to the next number in seconds.

Controls that raise the cost without punishing shoppers

Require a signed in session for a balance answer, and cap checks per account and per card per day. A shopper checks one or two cards. A tester needs hundreds of answers, so a low cap barely touches real use and breaks the economics of list testing. Where a card was sold through your platform, tie the balance view to the purchasing account when you can.

A challenge on the balance page helps, but place it after a small number of free checks rather than on the first one, or you train shoppers to hate a page they use once a year. Log every check with card identifier, account, and result band rather than exact balance, so the pattern stays visible to your team without storing a target list of loaded cards.

What to do when you find a run in the logs

Freeze the pattern, not the programme. Block the accounts and sessions doing the testing, keep the balance page up for normal shoppers, and pull the list of cards that were checked and later drained: those card ranges tell you whether the numbers came from rack tampering, which points at stores, or from a data leak, which points at your own systems.

Then tell affected customers before they find an empty card at a till. Draining victims usually discover the loss at the worst moment, and a platform that spots the pattern in its own logs and stays quiet owns that moment. A proactive credit costs less than the chargebacks and the story that follows.

Keep reading: Leaked credential checks at marketplace login: the free layer most sellers skip, Reading bot scores on a login page without drowning in false alarms.