Report leaked payment cards
leaked.cards
Any researchers who have spent any time investigating phishing or other criminal activity on the internet will likely have come across payment card details which have been captured from unsuspecting victims. In many cases this data will include PANs, expiry date, CVV, name of cardholder, address, phone number and other information.
The awkward truth though, is that many of these card details uncovered by researchers will never be reported to the banks for one simple reason - it’s an absolute pain to do so. Not only is the data typically messy but there is no central location for reporting this (until now!) so it takes a lot of work. We know this, because this same situation has happened to us on multiple occasions at Lab539 and it has meant that unless a leak is massive (or tiny) it’s just too much effort so we ignore it.
We didn’t like this. So we decided to do something about it. Welcome the imaginatively named “leaked payment cards reporting tool”. This tool is available online for anyone to submit leaked payment cards so that the information gets to the relevant parties. You can find this tooling here: https://leaked.cards (yes, we’re pretty proud of that domain!).
Our goal is simple, we want to ensure that we can do our bit in minimising losses to the victims of scams and breaches. This tooling is there for anyone who wishes to do their bit too.
Report leaked credit cards
Help ensure victims of cyber crime don’t lose out
Help disrupt the funding cycle of cyber crime
FAQ:
How do I report some leaked cards?
The process of reporting cards is pretty straightforward, you upload a text file containing the leaked cards to https://leaked.cards. If there is additional information such as expiry dates, addresses etc. then you should leave all of this information in there too. The back-end will do the hard work of making sense of the data. That’s it, you’re done.
What happens once I’ve uploaded a file with payment cards in it?
Once the data is uploaded the first thing we do is to make it inaccessible to everyone except the card issuers. We do this by extracting all of the Primary Account Numbers (PAN - the long number on the front of the card). We use the PAN to identify the card type (e.g. Visa/Mastercard/etc.) and also, where we can, the bank. After that the PAN is tokenized in a non-reversible manner and discarded.
What format does the file I upload need to be in?
Any plain text format is fine. e.g. .txt .csv
This is the format that researchers typically identify files of this type, but if you do uncover them in a different format such as .xslx or in some database format then most software will have some mechanism for coverting to plain text which can be used.
Should I remove all data other than the PANs?
No, the additional data is helpful. A PAN alone presents a very different risk to a PAN with expiry date, CVV, name and address so it’s helpful to leave it all there so the card issuers can assess the risk appropriately. We would therefore typically advise leaving the data in tact in the format you found it.
What is the maximum files size for upload?
Currently 100MB. If a lot of people need to upload files larger than this then we may look to accept .zip/.tar.gz files, but we don’t do this currently.
How are you storing the data securely?
Seeing as you ask, it wasn’t straightforward, but it was interesting…
We have a challenge in that we need some means for the banks, and for us, to identify whether we have seen a PAN before. Hashing PANs with a salt kind of does what is needed, but it is rainbow-tables-able and, whilst we’re not intending this to be the case, if our server were to get popped any salt we use could be obtained. Bearing in mind PANs are always 16 characters and start with a Bank Identification Number (BIN) this is a pretty reduced space so leaving it at salted hashes just isn’t sufficient in our eyes.
We can’t use something like bcrypt as that results in a different value each time given the same input so checking for matches would be infeasible. We should really use some asymmetric encryption (public-private key crypto) because that means we can encrypt with a public key and we don’t actually ever need the private key so that can be discarded. This, therefore helps with the “what if the server gets popped?” scenario too because no decryption key will ever exist on it. But the problem we have here is that good asymmetric crypto uses a seed value which results in different cipher-text each time when supplied the same value. This, therefore, doesn’t achieve our “same input must result in same output” requirement.
So the route we have gone down is a combination of things. Firstly we salt and hash the PANs. We then pass it through asymmetric crypto but with a static seed value. After that we salt and hash it again. This, therefore, results in the same output for the same input which is what we need. We feel a bit bad about weakening the crypto, but we couldn’t think of any other way around it and, after all, we are encrypting a salted hash of a PAN and the ciphertext is then salted and hashed again. To us this sound pretty decent, you’d need a couple of sets of rainbow tables and to have broken crypto in order to get anywhere, and realistically those rainbow tables would be impossible to compute without first compromising our infrastructure… There are definitely easier ways to get your hands on payment card details!
Our final hash is MD5, there will be some people that will rightly highlight thatMD5 which is not considered secure. We know. It’s just people have to read this data and this final hash isn’t really a security thing, it’s more just to bring it into a consistent format and anything longer than 32 characters is just a pain.
When it comes to the remainder of the data, that is a little bit more straightforwards, it is encrypted both using AES and RSA. This means we have some strong symmetric crypto as well as some strong asymmetric crypto. It’s the asymmetric crypto we’re most interested in here because, by not dropping any keys on the server, it means that even if we suffered a full compromise there remains little risk to the data.
We believe that this is a good, robust and secure way of doing things. If you think there are better ways that we could do this then feel free to let us know.
Is this service free?
Yes, and we hope to always keep it free for researchers and people submitting leaked payment card details. The whole point of the service is to take the pain out of reporting payment card leaks.
Is it anonymous?
Yes, kind of. You are not required to register to use the service and it is up to you if you want to leave additional information such as your name/handle or contact details - we don’t force you. We may at some point introduce a leader-board, some form of stats, or even the ability to reward reporters (but none of this exists right now).
In terms of data we log, we hold webserver logs, so IP, referrer, web browser. We hold this data for 1 year, predominantly for cyber security reasons (in case we need to investigate any security incidents).
We don’t ever store a copy of the file you upload (everything we need is parsed out of it) and since we only accept text files metadata would not present a concern. We do use Google’s reCAPTCHA so you may wish to familiarise yourself with their privacy policy.
If you think there is something we haven’t considered here then let us know. But the summary being, we have web server logs, that’s it and we don’t make any efforts to track people using the site.
Will you let me know if my submission has been helpful?
We know why you are asking this one, it’s always frustrating to submit something into a black hole. However, “if we can” is unfortunately the best answer we can give right now. Check back when we have a bit of momentum behind this and hopefully the answer will be “yes”.
Which banks do you work with?
We are happy to work with any bank or card issuer. If you are a card issuer and we are not currently in touch then drop us a message via our contact form and we can get you set up.
I am a bank/card issuer, how can i get set up?
Drop us a message via our contact form. It’s a manual enrolment process and we’ll need to verify you are who you say you are (obviously). But it shouldn’t take too long. If you have a public PGP key that you’d like us to use for encryption then let us know.
I am a bank/card issuer, how will you let us know if card details for our customers are uploaded?
We’re big fans of webhooks, so if you use MS Teams, Slack, Google Chat or similar we can drop you notifications when new PANs relevant to you are added. Or we can drop you an email if you’d prefer. Once we get you all set up you’ll be able to tweak and modify this however you like.
We follow a pretty simply approach to things at Lab539 - if something can be made easier freeing up time to make proper investments in cyber security then we should make that thing. Financial institutions around the world invest tens of millions of pounds in managing fraud, if we can free up some of that then excellent. But equally, security researchers are pretty busy individuals too. They don’t have time to be writing code to parse files containing breached payment card details in order to submit them individually to different card issuers or card brands. This tooling is written primarily for them, so that by simply uploading a single text file, in whatever format the found, all of the hard work can be done and they can sit back knowing that they have potentially saved individuals from having their bank balance drained by online fraudsters.