Card Wars: The Phantom Menace

August 5th, 2008 at 15:06 UTC by Mike Bond

Just like George Lucas can’t help but return to his old projects, I have been returning to mine. After three years of stagnation, I am pleased to announce the re-launch of phantomwithdrawals.com, freshly re-vamped, updated and turned into a wiki editable by the general public.

In fact, it’s not just great artists like Mr. Lucas and I starting up old projects, our honourable colleagues wearing the black hats have got the same idea. We have new victims reporting in, rumours abound of an auth system compromise at Citi, the Ombudsman is backlogged with months of disputed withdrawal cases, and some like Alain Job are even going to court.

One original contributor to the phantom case histories has just been hit by a second phantom withdrawal five years on and is chalking up another case in the files. While her new phantom is a bread-and-butter skim incident (a magstripe clone used in the far east), amongst this mass, true phantoms — the real mystery cases — are on the rise too. Two new victims with whom I have been corresponding very kindly offered to fund the hosting for the revamped site.

Let’s consider one of these mysteries. The McGaughey case has been reported in the media in Northern Ireland: dozens of withdrawals taking place over four weeks, totaling almost five thousand pounds, all within a ten mile radius of the McGaughey’s home. Summarised that way it looks like a classic first party fraud (couple short on cash withdraw money, then deny it later). But no-one in the family is short on cash, the McGaugheys look after their card details carefully, and have solid alibis at the time of many of the withdrawals, and the interlocking pattern of real and disputed withdrawals is such that any third party would have a hard time taking and returning the card (whether covertly or in collusion with the McGaugheys). No-one appears to have either the means or the motive.

Unusually the bank has been very cooperative, providing logs from their authorisation system (BASE24), including all of the cryptograms, input data and transaction parameters covering the affected transactions. Everything turns on the Application Transaction Counter (ATC), an on-card counter which increments with every transaction initiated. If an EMV chip can be fully cloned (secret keys and all), then it will have to submit an ATC value when transacting, and if used in parallel with the real card, it won’t be long before the same number pops up twice in the auth system, or large gaps in the sequence appear. The McGaughey’s ATC sequence appears to interlock perfectly: clearly the original card was used?

Of course logs can be misinterpreted (Badger) or even faked, auth systems may not work as expected, and customers may lie and cheat following all sorts of agendas; just around the corner the missing piece of the jigsaw may lie, which reveals the truth behind the case. And there is the totally separate matter of who should suffer the loss in the interim, whilst the truth remains unclear. Liability for disputed withdrawals is the most hotly contested issue of all.

phantomwithdrawals.com can’t do much more for the McGaugheys, but it can bear witness. Documenting the incidence of phantoms and the experiences of customers disputing them adds much needed transparency to the process, and helps researchers and experts seek out the really interesting cases.

Maybe we can lift the lid and discover the truth behind the “phantom menace” — everyone is united in that goal at least — but let’s also hope that Episode 2: Attack of the Clones has not yet started shooting!

Entry filed under: Banking security

2 comments Add your own

  • 1. Chris  |  August 6th, 2008 at 10:25 UTC

    “providing logs from their authorisation system (BASE24), including all of the cryptograms, input data and transaction parameters covering the affected transactions. Everything turns on the Application Transaction Counter (ATC), an on-card counter which increments with every transaction initiated.”

    I don’t get it. Surely if the bank can provide all the details of the above transactions, then they should know the exact shop the person was in, and the time of the transaction?

    As we are one nation under CCTV, and these transactions are occuring over a small area, then either the shops should have CCTV which would cover who at the checkout at the time of the transaction, or there would possibly be external CCTV in say a shopping centre to check whether this couple entered or left the shop.

    Even allowing for CCTV Uselessabilty (i.e. the vast percentage of cases where a CCTV camera is suddenly needed for evidence, but due to [insert random pathetic excuse] the video was not recorded) there should be enough CCTV cameras working to record at least 1 of the mystery transactions.

    So any reason as to why this isn’t being used?

    Chris

  • 2. Mike Bond  |  August 6th, 2008 at 13:36 UTC

    Chris, in theory yes all they need to do is to locate a disputed transaction, and get some footage of it to see who was responsible. I am not privvy to all the details of the example case I described of what they are and aren’t trying, I just provided some early advice via the phantom site.

    One problem is that while shops may be covered in CCTV, not all ATMs are (all the disputed withdrawals in this case were at ATMs). Crooks may know which ATMs are not CCTV covered and target these deliberately, and cameras integrated into ATMs are rather uncommon here in UK unfortunately compared with US.

    But yes you are right that CCTV *should* be able to help in phantom cases, I just think you underestimate the bureaucratic barriers to actually using it. In practice it is rather hard to get hold of CCTV unless it is a criminal case going to court, and by then it is often too late. Often by the time I get to hear of a case it is also too late to preserve the CCTV.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

August 2008
M T W T F S S
« Jul   Sep »
 123
45678910
11121314151617
18192021222324
25262728293031