TL;DR
Our credit card Canarytokens are out of beta and flying to your consoles!
- Create a [Canarytoken] credit card;
- Store it somewhere safe;
- If it’s ever used, we will let you know that “bad things have happened”.
We love these tokens because they provide a novel way to alert on a strong signal of badness. They also perfectly embody our concept of conspicuous deception. Conspicuous deception is our take that simply knowing that a credit card could be a Canarytoken adds risk to the process of stealing, selling, testing, and committing fraud on all cards. Now, fraudsters have to worry that testing or using a stolen card might be an immediate tip off.
Read on for step-by-step instructions for creating your first credit card token and suggestions for where to deploy them. For the really curious, we offer a behind the scenes look at how we got from last year’s beta to today’s launch.
Creating the new credit card token
We are slowly enabling these on Canary.tools consoles, if you are eager to try it, reach out to Thinkst Support and we’ll ensure we hit your console early. Once enabled, the new token will show up in the regular spot, along with the remaining issuable quota. Read on for step-by-step instructions for creating a credit card token.
Once you select the Credit Card token, you’ll see the remaining quota on your console. Be sure to put in a good reminder (usually where you will place the card):
After clicking “Create token”, you’ll see the details, which you can easily copy or download:
Now that the token is created, let’s issue a test transaction against it to make sure everything is working.
Once you click “Test Credit Card”, a payment dialog will appear, if you click the “Pay $100.00” button a legit transaction will be attempted using your new card.
We will let you know the status of the transaction as the vendor.
You should also hear the “pop” of a new alert!
Clicking on the alert provides some more information about the transaction: amount, date, and merchant. Use this feature to ensure that your team is ready to respond to a real alert.
That’s all there is to it! If you click off the modal dialogue, you can always return to the token details from the Canarytokens menu box.
Where to put ‘em
Every environment is different, so prescribing a generic use case is tough. If you make good use of the memo-field (“Placed in root drive of DB-Server”) and make sure you place them in unique locations, a single alert can be all the help you need to pin-point a breach.
- Most organizations shouldn’t be storing payment information (and instead tokenizing it through their payment provider), but there are exceptions. If your organization is storing customer payment information, mix in these token cards–remember you can make up any name or billing address.
- Alternatively, putting the token card information in an internal email can act as an alert on email compromise. There are tools like PANhunt that search filesystems and PST files (Outlook mailboxes) for payment card details which can help act as a clear indicator of network breach.
- Another deployment strategy is adding it to travel information on a fileshare, as a way to detect malicious insiders. At a previous employer, our corporate card details were all in shared Word documents to allow for the travel team to book travel while keeping Accounting happy.
Stepping back
The idea behind the credit card token was to be able to give users a unique credit card number, they could put that somewhere in their environment. If a transaction was ever attempted, the card would be declined, and it would alert the token creator of the attempt–allowing the user to quickly catch network breaches. This token should give a really strong signal of badness with no false positives in the event of a real attack. No pentester should be trying card numbers, so the token can really provide a very clear signal of a real attack.
Last year we released the Canarytoken as a limited beta. Demand was far greater than we expected, causing our service provider to implement rate limits on new credit card generation. Very quickly many Canarytoken.org users were getting errors, and even with our behind-the-scenes fixes, we kept running into limits.
Even though we issued thousands of cards, we ended up deciding to pull new token generation until we could figure out a better solution. (All previously-issued beta tokens will continue to alert–the most important thing for us is to make sure users get that alert when it matters).
We knew if we wanted to match the demand for this token, we’d have to find a new provider.
The majority of the time since releasing the beta token has been spent communicating with financial institutions and fintech platforms to see if they could support our unique use case. These businesses make their money through swipe fees. Swipe fees are a percentage of each transaction that the merchant pays to accept cards. They are divided by the: card issuer, issuing bank, and any other party involved with the issuance of the card. There is a reason that every time you shop at a large store chain or fly you are plied with offers of that company’s branded card–they get a small percentage of each transaction.
When we approached most platforms, we heard the same story: the token model doesn’t fit into their business models. We would issue large numbers of cards, and have $0 of spend. The issuing platforms bear a small cost for each card issued, but would be in on the swipe fees, allowing them to recoup those initial expenses. Our proposition to never give them a path toward the green wasn’t well-received, especially because these tokens would likely have more fraudulent transactions than average. With the beta tokens, there were many instances where a user would receive a credit card number and try to spend money on it, or register for services. Even though these were declined, there can be costs and risks associated with this unpredictable behavior.
Finally, we found a provider that was willing to build a custom pricing model for our tokens: AirWallex. AirWallex was willing to issue our tokens (for a fee per card) knowing that they will not make any revenue from swipe fees. They have a mature API, and are multinational, allowing us to (potentially in the future) offer tokens with multiple countries of origin and BIN ranges.
Another benefit of AirWallex is that their API also allows for notifications of cards being tested that trigger 3D Secure (3DS), a 2FA scheme that texts or emails a code to the cardholder before approving a transaction. Without this added visibility, a transaction attempt that ran into 3DS and then never proceeded would time out, not generating a full transaction attempt and corresponding alert.
Now that we had a provider, it was time to get to work.
Making it rain
With a more reliable financial card platform, work got underway to implement the new token type into customer consoles. We still think that offering the tokens freely on Canarytokens.org helps with conspicuous deception. However, our paying customers are more likely to have real payment information stored in their environments that would benefit greatly from having early warning of compromise. Additionally, as those organizations often have closer relationships with their own banking partners, they have existing channels to quickly put fraud protections in place for co-resident cards.
This token type has a few distinctions from our existing offerings, namely that:
- It costs us real money per token we provide
- The token cards expire over time
- The unnecessary alerts can strain Airwallex’s ability to onboard us with new BIN ranges.
We’ve offered unlimited tokens for all of our token types, generally their infrastructure and associated costs are loosely related to the volume of tokens issued or the number of alerts–for this token it’s directly related to volume of tokens issued. For this reason we are providing each console with a quota of tokens available to be issued. If you need more, reach out to us and we can bump up that quota for you.
If you require an extreme number of them (e.g., deploying tokens to each physical location), we’ll work with you to find out how best to provide this unique capability.
As we all know from having real payment cards, they expire over time. Our existing tokens generally last without maintenance, so this is a shift where there is a bit less “forget about them” and a bit more “set a reminder in a couple of years”. After the cards expire, they will be declined due to an out-of-date error, and the transaction data will not be passed to AirWallex (and then us) for alerting. As tokens are approaching their expiration date, you’ll get a reminder to issue a new one.
While AirWallex has built a cost model for our highly irregular usage, there are reputational risks associated with a higher-than-average decline rate. As these token cards will never have a successful transaction in their lifetime, excessive transaction attempts on the cards cause them headaches.
To mitigate some of these concerns, we built a tiny testing feature for your newly-minted credit card token. From the console you can issue a test transaction through the platform to testalerting, SIEM integrations, etc. without harming provider risk calculations.
While we are providing our customers with these tokens, we are not doing so for them to charge money against them. With the beta tokens, there was no way to make sure they worked without actually attempting a transaction. In some jurisdictions, this could be considered attempted fraud (or make for a very awkward trip to the nearby store), so we’d rather leave that to the criminals–just use our testing feature.
Conclusion
We’re thrilled that the credit card Canarytoken is out of beta and will be arriving at a Canary Console near you soon! Like other tokens, these are designed to be simple to deploy and alert when it matters. We are bringing the token back to the Canarytokens.org site as well, with per-day rate limits. Keep hitting refresh over there if you’re not a customer–while you wait you can check out some of our other great tokens!
We think that our deception approach wins either way: loud/clumsy attackers trip over our Canaries or Canarytokens and get caught, while savvy attackers are forced to move slowly and fail to accomplish all of their goals out of fear of getting caught. For the credit card token, we see this same pattern: a loud attacker will attempt to use the card, cause an alert, and the customer can quickly prevent additional fraud (and know their network was breached). A more clever attacker may keep stealthy, but only by giving up the value from the stolen cards.
We hope you will find these as exciting as we do, enjoy!
