Credit card fraud - what's in it for the fraudster?

[RogerS]

SWMBO noticed a fraudulent transaction (£600 plus) on her John Lewis card the other day. Leaving aside the fact that this transaction was so far out of her normal spending pattern that it doesn't say much for any anti-fraud algorithms John Lewis might have in place (as it wasn't picked up by them), I don't understand what benefit the fraudsters got.

The transaction went through hotelopia.com which is a hotel, car, transfer and activity booking site. Maybe the fraudster has got nerves of steel but paying in advance, say, for a hotel is surely leaving them wide open to the card holder spotting the fraud, contacting the card company etc ....but maybe the fraudster knows that this will take time and so they will have long gone from the hotel? Car hire....ditto. Refunds wouldn't work because they go back to the same card.

Anyone else any ideas as to what benefit the fraudster might get?

The scary thing is that when you go through the hotelopia website and make a booking, you are asked for the CVC number (ie the 3 or 4 digit security code on the card). This is supposed to prove that the person making the transaction has the physical card in their presence. Or not. Thing is when i dug a bit deeper, the payment organisation passes back to the merchant (hotelopia) a value based on how much of the information, such as CVC or address (although the latter is not asked for in this instance), actually matches what the credit card company holds. Now if Hotelopia's software (you can read the source code quite easily but I'm not up to speed to determine whether they bother with the CVC score or not ) ignores the CVC then that would explain why the transaction went through.

Or maybe the CVC is held 'in clear' by some other merchant that my wife dealt with in the past. It's easy enough looking at the code to store those details.

But does seem to throw a question mark on the relevance or validity of the so-called 'security check' CVC.

 

[mseries]

Thing is when i dug a bit deeper, the payment organisation passes back to the merchant (hotelopia) a value based on how much of the information, such as CVC or address ... actually matches what the credit card company holds. Now if Hotelopia's software (you can read the source code quite easily but I'm not up to speed to determine whether they bother with the CVC score or not ) ignores the CVC then that would explain why the transaction went through.

Can yo really read the source code ? How ? Is it open source ? It's the calculation of the 'score' that you need to understand and how the hotelopia software processes that value. The source code shouldn't be made public, not by the payment company not hotelopia.

 

[RogerS]

You mean not like this ...

checkCreditCar = function (cardType) {

if(!cvcExempt){
if(cardType == 'MAESTRO-SSL'){
$('#cardcvc').removeClass('requerido');
$('#cvcrequired').hide();
}else{
$('#cardcvc').addClass('requerido');
$('#cvcrequired').show();
}
}

var content = "";
if(cardType=="AMEX-SSL"){
content = "<img src='img/cvcinfo-amex.png' style='float:left;'/>"+window.msghelpcvcamex.valueOf();
}else{
content = "<img src='img/cvcinfo.png' style='float:left;'/>"+window.msghelpcvc.valueOf();
}
$('#cvcHelp').attr('title', content);
$("#cvcHelp").tooltip({align: 'top', html: true});

if ((cardType != 'EURO6000') && (cardType != 'ELV-SSL')) {
$("table.payment_information .CardFields").each(function (i, el) {
$(el).removeClass("hidden");
$(el).addClass("unhidden");
});
$("table.payment_information .maestro").each(function (i, el) {
$(el).removeClass("unhidden");
$(el).addClass("hidden");
});
$("table.payment_information .EcKarte").each(function (i, el) {
$(el).removeClass("unhidden");
$(el).addClass("hidden");
});
$("table.payment_information .bank").each(function (i, el) {
$(el).removeClass("unhidden");
$(el).addClass("hidden");
});
$("table.payment_information .cardowner").each(function (i, el) {
$(el).addClass("unhidden");
$(el).removeClass("hidden");
});
}
else if (cardType == 'ELV-SSL') {
$("table.payment_information .CardFields").each(function (i, el) {
$(el).addClass("hidden");
$(el).removeClass("unhidden");
});
$("table.payment_information .cardowner").each(function (i, el) {
$(el).addClass("hidden");
$(el).removeClass("unhidden");
});
$("table.payment_information .EcKarte").each(function (i, el) {
$(el).removeClass("hidden");
$(el).addClass("unhidden");
});
$("table.payment_information .bank").each(function (i, el) {
$(el).removeClass("hidden");
$(el).addClass("unhidden");
});
$("table.payment_information .maestro").each(function (i, el) {
$(el).removeClass("unhidden");
$(el).addClass("hidden");
});
}
else if (cardType == 'EURO6000') {
$("table.payment_information .CardFields").each(function (i, el) {
$(el).addClass("hidden");
$(el).removeClass("unhidden");
});
$("table.payment_information .EcKarte").each(function (i, el) {
$(el).removeClass("unhidden");
$(el).addClass("hidden");
});
$("table.payment_information .bank").each(function (i, el) {
$(el).removeClass("unhidden");

That phrase if(!cvcExempt){ worries me.

It's dead easy to read the source code. Make a booking, go through to the payment page, view source.

 

[mseries]

all that code snippet is doing is determining whether or not to display the entry field for the CVC depending on the card type. At some point the entry fields on screen get submitted to a server

The source of the page in the browser is different to the source of the code that does the processing in the server and it's the latter to which I was referring.View Source doesn't show the server source code.

 

[mseries]

if (!cvcExempt) {

is saying if NOT cvcExempt, we can't see how cvcExempt is determined, it's value is true or false, maybe the same script is used for different vendors and some require CVC to be entered and some do not. So in your exemple if not cvc exempt, that is cvc is required, proceed to determine if cardtype is MAESTRO_SSL or not, and if it is remove the requerido class from the cardcvc field and hide the cardcvc field,otherwise show the field with class requerido

 

[mseries]

CVC isn't required for a payment to go through, maybe hotelopia ask for it but don't make use of it. Maybe this transaction was a tester for something else, just to see if the card was still valid.

 

[RogerS]

Thanks for the very useful insight.

Interesting if they don't bother with CVC then that leaves the site wide open for fraudsters to use other people's cards. Like my SWMBO's.

Presumably there is nothing to an e-commerce site capturing and saving the CVC data.

 

[AJB Temple]

Roger, you cannot get to processing source code in the way you describe. You can sometimes see some of the front end screen dialogue code as you have found here, but the real work will be done behind firewalls.

Practically all financial services companies use electronic id and anti money laundering checking software these days, and this can be done in the background whilst you re on line or on a call. This software operates, simplistically, a scoring system to determine whether the transaction / person should proceed. There are often a number of fail points but the business will have a trade off between risk of running the transaction and the hassle caused by undertaking further id procedures. A common fail point is bank accounts: many people opened bank accounts before databases for id checking came into common use in the early 80's and so older clients will often fail a Tracesmart (or similar) check on this.

CVC data should not be retained by reputable companies and usually the on-line payment code will prevent this. Problems do occur with recorded telephone transactions. You can put white noise over the sensitive data that should not be retained. It is not by any means fool proof.

Incidentally, John Lewis will not be operating the account and none of the code will be theirs except for the front end web access code. Their financial services offshoot is not a bank. I believe it is in fact a white labelled service operated by HSBC.

 

[mseries]

Thanks for the very useful insight.

Interesting if they don't bother with CVC then that leaves the site wide open for fraudsters to use other people's cards. Like my SWMBO's.

Presumably there is nothing to an e-commerce site capturing and saving the CVC data.

maybe the fraudsters simply 'guessed' the cvc in this case (using a script to fire transactions to the site trying different values)

 

[RogerS]

Yes, I appreciate that. There are at least two levels as I understand it. One is at your credit card provider who will (usually) have some form of automatic algorithm in the background checking to see whether or not the amount and type of goods or services being purchased aren't out of the 'norm' which in this case failed spectacularly. Organisations like WorldPay are a gateway and will pass back to the merchant, in this case hotelopia, the score. It is at this point - hotelopia - where the second check will come in as they can decide what level of 'score' they will accept. (I know that there is a separate authorisation stage which reserves funds). I'm not concerned about this background stuff.

But my point is that the CVC data can be stored. For example, this code on hotelopia takes the CVC as input.

<input autocomplete="off" maxlength="4" name="cardcvc" id="cardcvc" class="requerido input-border" type="text" size="10" />
<a href="#" id="cvcHelp" title="<img src='img/cvcinfo.png' style='float:left;'/>The security code is a 3 or 4 digit number (depending on the card), found on the back of your card.">What is this?</a>

So in the case of my wife's fraudulent transaction, either the fraudster has captured her CVC number somehow (from another website transaction) and seeing how easy that source code is to get at, I am sure that a hacker could compromise a smaller less-IT savvy e-commerce company by injecting code in to store the CVC number etc.

Or hotelopia ignore any low score due to an incorrect CVC being entered. That decision criteria will be there in the visible source code but my HTML isn't up to the task.

mseries....that's a possibility.

 

[RogerS]

Any ideas on what the fraudsters got out of it?

 

[Flynnwood]

Any ideas on what the fraudsters got out of it?

One (very remote) possibility is that an employee put the transaction through, but then refunded the money to a different outcome (i.e. cash, or to another card or bank account).

It's unlikely but possible. It might take the company some time before they realised that refunds were being done in such a manner (even if it was against company policy).

 

[RogerS]

Any ideas on what the fraudsters got out of it?

One (very remote) possibility is that an employee put the transaction through, but then refunded the money to a different outcome (i.e. cash, or to another card or bank account).

It's unlikely but possible. It might take the company some time before they realised that refunds were being done in such a manner (even if it was against company policy).

My understanding was that credit card refunds could only go back to the credit card from which they were drawn.

 

[mouppe]

A booking can generate a commission for the agent, even if it is later refunded. Do this many times and the sums can add up to something considerable. We had to fire somebody from our agency for doing exactly this. He was in cahoots with somebody from the university's travel department who made loads of reservations and then cancelled them.

 

[Flynnwood]

Any ideas on what the fraudsters got out of it?

One (very remote) possibility is that an employee put the transaction through, but then refunded the money to a different outcome (i.e. cash, or to another card or bank account).

It's unlikely but possible. It might take the company some time before they realised that refunds were being done in such a manner (even if it was against company policy).

My understanding was that credit card refunds could only go back to the credit card from which they were drawn.

Not true. It would be company policy yes, but a bent employee could issue a refund to another card.

It would just be a credit, rather than a debit.

The unknown variable is how long it would take the company to discover such activity. It might be a day, a week, a month or more (depending on how strictly enforced the policy/banking procedures are adhered to).

 

[RogerS]

Ah thanks for that...interesting. That would be a very easy way of getting the money out.

 

[mseries]

But my point is that the CVC data can be stored. For example, this code on hotelopia takes the CVC as input.

<input autocomplete="off" maxlength="4" name="cardcvc" id="cardcvc" class="requerido input-border" type="text" size="10" />
<a href="#" id="cvcHelp" title="<img src='img/cvcinfo.png' style='float:left;'/>The security code is a 3 or 4 digit number (depending on the card), found on the back of your card.">What is this?</a>

So in the case of my wife's fraudulent transaction, either the fraudster has captured her CVC number somehow (from another website transaction) and seeing how easy that source code is to get at, I am sure that a hacker could compromise a smaller less-IT savvy e-commerce company by injecting code in to store the CVC number etc.

yup, the data is sent to a server, hopefully securely for processing. Unscrupulous organisations could store the details, or as you say you may have visited a hacked site that's stored it. If the form isn't submitted securely the data is open to a man in the middle attack where someone intercepts the data, copies it and sends it on. Don't underestimate hackers, they are professionals with lots of time, patience and resources.

 

[RogerS]

Interesting Panorama programme tonight. Didn't learn anything much other than the fact that some companies clearly do store the CVV/CVC number which then becomes available to fraudsters on the Dark Web. Which clearly is what happened to SWMBO's card details. Or something very similar.

 

[AJB Temple]

I happen to work as a professional in the financial services industry. I have worked in professional advice, regulation, fraud investigation, bank supervision and commercial fields. Despite this I have experienced id theft and seen a lot of fraud. It is very difficult and inconvenient to guard against it perfectly as we all need to have a degree of convenience.

My personal mantras:

1. Create a fake online persona that you use consistently for internet purposes: false DOB, false mother’s maiden name etc
2. It can be a good idea to have a small spelling mistake in your name and address: this helps add traceability
3. Use a disposable email address for all internet shopping – never use your main email address: keep that strictly for trusted people
4. Never reply to spam in any way that shows you are a live email address
5. Use keychains or keylocks to store passwords, and make them strong (letters, u/c and l/c, symbols and numbers). There is a lot of readily available software around that can crack simple passwords faster than I can type this sentence
6. Make sure you can wipe your laptop and mobile phone remotely
7. Always have access to your computer turn off after a short period of non use
8. Be aware that backups on hard drives such as Time Machine have virtually no protection
9. **** site are full of malware – if you want to browse **** use an iPad or similar tablet and ONLY that
10. Always unsubscribe from marketing mails from internet sites
11. Use a credit card not debit card for all internet shopping. Try not to have it linked to your main bank account and make sure the total credit limit is at a figure you can afford to lose. Do not let the provider increase it. Tell them in writing that you have a self-imposed limit for fraud protection. This can help you a lot in an eventual FSCS claim situation
12. Don’t use cheques – they hold too many financial details
13. If you use Facebook and similar, don’t be surprised if your personal details are harvested
14. Be very wary of what personal details you put on Linked In and similar networking sites
15. Be aware of where your data is stored for cloud storage and email – if you use apple mail, google mail, Hotmail etc then all your data is going through US servers and you have virtually no data protection act protection. It’s a choice but make choices without ignorance
16. Dropbox is very convenient. But it is not secure. Just be careful what you store there and make sure you can afford to lose it
17. If you use meail at work your employer can see it
18. Just because you think you have deleted it, it is not in fact deleted in most cases
19. Location services in mobiles enable you to be tracked with great precision. Make sure you understand that
20. You can install free ad blockers. Do so, it reduces tracking a lot

I could go on, but that is enough ;-)

Adrian

 

[RogerS]

Adrian..some sage words. I'd add a couple more.

21 Never use something like Lastpass as any of those password storage places are a magnet to hackers.

22 Tie your PayPal account to a dedicated bank account other than your main bank account. Transfer funds from your PayPal account to that dedicated bank account as much as is practical at any given moment. Then transfer that money from your dedicated bank account to your main account. That way not only are you protected a bit from any hackers but also from PayPal riding roughshod.

23 Use a low-limit credit card tied in to your PayPal account.

24 Use TFA if possible.