Category Archives: Breach Analysis

Velocity Checking: One lesson everyone can learn from Tesco Bank

Like many credit and debit card acquirers, when Tesco Bank’s fraud system detects what it thinks is a fraudulent transaction on a cardholder’s account it sends the customer an SMS saying “please contact the bank”. It’s pretty obvious that it doesn’t have any sort of velocity checking on this function — which is why, on the weekend of 5-6 November, over 20,000 Tesco Bank customers received such a text message. Many reported spending a few hours on hold to the contact centre.

You can be sure that if you send out 20,000 SMS fraud alerts, a large percentage of those people will contact you — and Sunday morning is not when the contact centre is going to be fully staffed!

What went wrong

The fraud system should have not treated each fraudulent notification in isolation, but it should have also created a consolidated view across the entire system. As soon as the consolidated view noticed it had sent out an abnormal number of alerts in a 10-minute period then it should have:

  • Paused sending out alerts to customers
  • Sent an alert to the SOC saying “Help, I’ve seen fraud on 2,000 accounts in 10 minutes which is five times more than normal. I think we’re under attack and can you get more people in the call centre for tomorrow morning?”

Of course – the system could also have been clever enough to notice that all these alerts were caused by the same sort of abnormal transaction (in this case magnetic stripe contactless debit card transactions from outside of the UK) and the system could have also set this transaction type to auto-decline. This would have perhaps had the benefit of stopping the fraud continuing.

Lessons for everyone

It’s not uncommon for developers to think of a problem in isolation: “if X happens then assume this account is being attacked so do Y” but developers should also think of the system-wide view. There must be something in a system to address the question “is it just one account that’s being attacked, or is this part of a systemic attack?” Fixing this can be as simple as writing to a log that another process is monitoring — looking for patterns and abnormal velocities — which can then follow its own business rules to detect and respond to systemic attacks.

We can all learn this one lesson from Tesco Bank: think systemically. If you have a system that sends SMSs to customers asking them to call you, or something that locks accounts after ‘n’ bad attempts, how would your organisation respond if 20,000 people tried to call you at the same time?

Consider the OWASP AppSensor

There’s some great thinking about how to get applications to think on a system-wide basis in the OWASP AppSensor project.

Was Tesco Bank hacked?

I’ve read some pretty amazing articles and blogs in the last week that show quite a misunderstanding about how criminals steal money, how payments work and how the new General Data Protection Regulation would both punish Tesco Bank and simultaneously remedy all ills. Cyber security and financial crime is a complex subject and I thought I’d try to look at whether (or how) Tesco Bank was “hacked” a couple of weeks ago.

The short tl;dr version is:

  • No, I don’t think Tesco Bank was hacked – but I think someone else that has lots of Tesco Bank debit card numbers has suffered a breach of confidentiality.
  • Tesco Bank had a problem with how it authorised Magnetic-Stripe-Contactless transactions. That problem could have been misconfiguration, programming error or criminal control of the authorisation system.

If you’re interested in the long version …

I’m going to start with a quick review of the way that money can be taken from current accounts.

1. How criminals steal money from current accounts

Ignoring kinetic / analogue methods, there are two conceptual main ways for a criminal to extract money from customers’ current accounts:

  1. Push transactions – where the funds are pushed from the customer’s account to the criminal’s
  2. Pull transactions – where fund are pulled from the customer’s account.

1.1 Push Transactions

  1. The criminal can compromise the bank’s internal systems, and transfer money directly from multiple customer accounts to accounts owned by the criminals via faster payments / BACS.
  2. The criminal can gain access to the customer’s online banking credentials and then login to online banking, masquerading as the customer and initiate money transfers (faster payments/BACS) or standing orders to accounts owned by the criminals. Criminals can gain access to these credentials either by:
    1. Compromising the bank’s internal systems
    2. Tricking the customer into downloading / installing malware onto their machine which captures the banking details (or manipulates transactions within the browser) – e.g. the Zeus, Panda and Dyre banking trojans.
    3. Sending phishing emails to customers to encourage the customer to divulge their credentials to the criminal
    4. Where banks use simple authentication methods to manage login such as simple ID and password, criminals could re-use IDs and passwords captured from other sites.
  3. Compromising the bank’s webserver and deliver rogue JavaScript to the customer’s browser included in the online banking web page. The criminal JavaScript can then act as a browser-based key- or form-field logger.

1.2 Pull Transactions

  1. The criminal can submit false direct debit instructions.
  2. Where customers have a debit card associated with a current account the criminal can submit a false debit card transaction to the bank. This allows the criminal to get cash, or goods which they then can resell for cash. This transaction could be one of eight types.
    1. A magnetic stripe transaction with PIN to withdraw cash from a non-chip enabled ATM
    2. A magnetic stripe transaction without PIN to purchase physical goods (that the criminal can resell to get cash) from a retailer (in a non-chip and PIN region)
    3. A magnetic stripe equivalent contactless transaction in pre-chip markets (such as the USA)
    4. A Chip and PIN transaction to withdraw cash from an ATM using the cardholder’s card
    5. A Chip and PIN transaction to purchase physical goods from a merchant using the cardholder’s card.
    6. A chip-based contactless transaction (as used in Europe)
    7. An online, e-commerce transaction to purchase physical or digital goods from a retailer
    8. An on-line e-commerce transaction to top up a pre-paid card or pay off a credit card balance – effectively using the debit card to transfer cash to another type of account.

2. What we know

Tesco Bank has reported that about 9,000 accounts were affected and that £2.5 million had been taken from current account customers.

In the immediate aftermath on the morning of Monday 7 November the Bank initially suggested that 20,000 accounts were affected, and that it had stopped potentially fraudulent transactions on 20,000 more.

2.1 What transactions were blocked?

The Bank has been very careful not to use the word hacked. Initially the Chief Executive used the phrase “a systematic, sophisticated attack” and on the Bank’s update page it answers the question

    “Should I change all of my online banking and personal details that you hold?”

with this:

“Tesco Bank has not been subject to a security compromise and it is not necessary for customers to change their login or password details.”

This statement rules out Push methods 1,2 and 3 above as if the online banking system or Tesco Bank’s systems that control this had been compromised, users would have been forced to change their credentials.

Looking at both Tesco Bank’s own online forums and those of Money Saving Expert , it is possible to conclude that the “sophisticated attack” was a pull-type attack using debit cards. The following posts are from Tesco Bank representatives (with my emphasis) on the Tesco Bank community forum:

“Yesterday evening, we identified some suspicious activity in a small proportion of our customer’s current accounts. We have taken steps to protect these account holders and are contacting affected customers by text message. We can reassure our customers that they will not lose out as a result.

All of our customers can continue to access their accounts through online banking and can make chip and pin transactions.”

“We have taken the decision today to temporarily stop online transactions from current accounts. This will only affect current account customers. While online transactions will not be available, current account customers will still be able to use their cards for cash withdrawals, chip and pin payments, and all existing bill payments and direct debits will continue as normal.”

“Hi @TescoBank, does the section above refer to online card payments to retailers, or to Faster Payments I want to make from my account online, or both?
Hi @xxxxx, this refers to online payments to retailers. You should be able to make a Faster Payment as normal from your account by logging into online banking.”

“Hi @xxx, your card has been cancelled but rather than place a full block on the account you are still able to use the card at an ATM and for chip and pin transactions. You’ll be unable to process contactless or online transactions.”

“If you’ve received this text then we will need to have a new card issued to you. Whilst you’re waiting on this you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones. Please continue to monitor your account over the next 7 – 10 working days for any suspicious activity and if you notice anything please get in touch.”

These statements rule out the pull method 1 and pull methods using chip-based debit card transactions described above although there is an apparent inconsistency in allowing chip and PIN but blocking a contactless transaction (as contactless in the UK uses the chip as part of the transaction).

2.2 Unused cards compromised?

Additionally a number of customers complained about debit card transactions using cards that had “never been used” (it seems from forum posts that a number of people used their account as a savings vehicle rather than a traditional current account, given the 3% interest paid).

“I have not used this card in a card machine or used it online”

“Given that both myself and my daughter received the suspicious activity text message for cards which arrived in sealed envelopes and have NEVER BEEN USED there is no doubt that Tesco security is sadly lacking.”

“I received both text messages however, what concerns me more is the fact I’ve never used my Tesco Bank card (online, in-store etc). It is still attached to the welcome letter.”

“I have never used any of my cards at any time and never ever done an online transaction using this account, it’s been purely used as a savings vehicle.”

2.3 Contactless fraud report

On the 13th November, the Sunday Times (and Sun) reported that:

“The money was stolen from Tesco Bank accounts by a criminal gang purchasing thousands of low-priced goods using contactless mobile phone payments at retailers in the US and Brazil, including Best Buy.”

So it appears that there have been fraudulent online debit card transactions (and if the Times story is true, contactless debit card transactions) attempted against somewhere between 9,000 and 40,000 Tesco Bank accounts, which were successful against 9,000 accounts. Given the amounts that have been quoted in the forums by account holders (£20.63, £9.33, £827.30, £533.00, £549.31, £28.50 etc) these were not fraudulent ATM transactions as the amounts reported do not appear to translate to round-number values (in GBP or USD), so the transactions look like they happened in a retail environment.

3. Ways to make fraudulent debit card transactions

To make a fraudulent e-commerce retail transaction a criminal would need a combination of the customer’s debit card number (the 16-digit primary account number or PAN), the card holder name, card expiration date and CVV2 security code I say ‘a combination’ because it depends on how much information Tesco Bank requires to authorise a transaction, and how much information the merchant captures at an e-commerce sale.

It is also possible to use the debit card number, expiration date and CVV2 in a normal merchant terminal if the data is keyed into the system using the keypad in a face-to-face environment such as a store (normally used when the chip/mag stripe fails or to process a mail-order/telephone order transaction).

3.1 The contactless conundrum

It’s interesting that both the Times and Tesco Bank themselves mentioned contactless. I was confused when the post on Tesco’s online form said “you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones” because in the UK a contactless transaction uses the same security as Chip and PIN; the contactless transaction uses the chip which actually digitally signs the transaction, making fraud really hard because you can’t just steal data and make a clone chip card.

However, the Times reports that the fraudulent transactions occurred in the US and were reported as “contactless mobile phone payments”. If this is true (and I’ve not been able to verify this from a second source) it narrows down the way that the criminals worked because Tesco Bank does not support the two common ways of making contactless debit card transactions: ApplePay and AndroidPay for its Visa debit cards (only ApplePay is supported on the Tesco Bank MasterCard credit card). Given the way that cards are loaded into ApplePay and Android pay, that’s not something the criminals can forge (as far as I am aware) because it requires the active participation of the issuing bank. So if the Times is correct then here’s what I suspect has happened.

In the US a technology was developed called LoopPay ( which used an electromagnetic field to make an old-fashioned magnetic stripe transaction on a non-contactless terminal. The consumer ‘loaded’ their card details into LoopPay and it could be used with any magnetic-stripe reading terminal by just holding the device near the terminal. The LoopPay system generated an electromagnetic field to ‘give’ the data that would be on the magnetic stripe to the old-fashioned card reader.

This technology was bought by Samsung and the hardware to generate the magnetic field is built into the latest Samsung phones. Although using the Tesco Bank debit card is not officially supported by SamsungPay, it would be possible for a criminal to have used the technology to just load Tesco Bank card details into a Samsung phone by writing their own software. When I worked at Visa Europe we were very sceptical about this technology because it doesn’t allow the merchant to validate the signature and all the security features on the physical card (there’s a reason the whole industry spent fortunes on holograms to stop people making fake cards). So that’s one option if mobile phones were used – I’m going to call this ‘electromagnetic magnetic stripe emulation’ or EMSE.

There’s also another possibility: in the US there’s an old-fashioned sort of contactless transaction that pretends to be a magnetic stripe, it was developed before the chip (EMV) version of contactless which is what we use in Europe was deployed. It isn’t as secure as the chip version and wasn’t widely supported in the US – but it could also be that the criminals worked out how to load a Tesco Bank card into an Android phone which emulated the US Magnetic Stripe Contactless (MSC) type of transaction. If the Times story is true then my instinct is that the attack would have used either EMSE or MSC.

Even then the criminal would need more than just the card number – there’s a secret card verification value (CVV) encoded on the magnetic stripe alongside the account number that the card issuer (i.e. Tesco Bank) should validate when it approves a magnetic stripe transaction.

4. Two key questions

There are two key questions to be answered:

  1. Where did the criminals get the data from that they used to make fraudulent debit card transactions?
  2. How did they make those transactions in a way that they would be authorised by Tesco bank, and not identified as fraudulent transactions and rejected?

4.1 Data

Firstly then as there were fraudulent transactions made against (let’s say) 20,000 Tesco Bank current accounts – where did the criminals get the card data from?

There are six possible options:

  1. They stole it from another online retailer.
    I’m going to suggest this as the least favourite option because the attack was just against a Tesco Bank. If the criminals stole this much debit card data from another retailer, then lots of banks would have been attacked, because if the criminal got the details of 20,000 accounts out of Tesco Bank’s 130,000 accounts it means they have lots more HSBC, Lloyds and Barclays to use. And given that Tesco Bank only has 130,000 accounts out of a UK population of around 30 million debit cards, the only place that a criminal would be able to get say 20,000 would be a retailer taking something like 90 million card payments a year. Of course this could have happened, and the criminals only targeted Tesco Bank, or every bank was targeted and only Tesco Bank had a ‘problem’ with how it authorised transactions. But if this were the case I think we’d have heard about it. If this has happened, there’s a very big data breach from a retailer hiding in the wings.
  2. They aggregated it from lots of other online breaches over the past few months because they were particularly targeting Tesco Bank as they were aware it had a problem with how it authorised online/magnetic stripe transactions and so would provide a way of extracting cash that they couldn’t do from the other UK banks. Again, because of the small number of Tesco Bank cards in circulation, this seems to be unlikely.
  3. They obtained the card data from on-line banking attacks against the customers through phishing or malware on the customer’s machine. Tesco Bank was the subject of several high-volume phishing attacks earlier this year. However this is unlikely given that the Bank has made the assertion that customers need not change their passwords.
  4. They stole it from Tesco Bank.
    I’m going to suggest this is unlikely. Given that the public statement that “Tesco Bank has not been subject to a security compromise” and given the way that the Bank handled its press incident response this week, I’d be astounded if the bank was lying about this and would risk the enhanced regulatory wrath that a deliberately misleading public statement would generate.
  5. They stole it from another part of the Tesco group (such as Clubcard accounts) that has access to Tesco Bank debit card numbers or Tesco retail stores where Tesco Bank debit cards would be more highly utilized.
  6. They stole it from a third party — such as the company that made the cards or one of the third-party processors that Tesco Bank uses. This is not impossible as it is well-known that Tesco Bank outsources many of its core banking systems. But again I come back to Tesco Bank’s own statement that the bank hasn’t been subject to a security compromise and again I’d be surprised, given how closely the regulator will look at this incident, if this was weasel-speak to cover up a third party breach. I’m also aware of the security audits (from Visa etc) that the card manufacture and personalisation companies have to go through and I’m going to say this is an outside possibility.

Made up random card numbers?
There’s also another (improbable) option, that the criminals didn’t steal the debit card data, they just made Tesco Bank debit card numbers up at random, and tried them!

The numbers of all Tesco Bank debit cards will start with the same first six digits – this is known as the Bank Identification Number or BIN. For an example let’s assume this is 468738 – the criminal could guess a valid card number would be 4687 3800 0000 0008 (because of the way the checksum works with card numbers, this is the first valid card number that would begin with 4387 38 – the next one is 4687 3800 0000 0016). So the criminal can generate many thousands of valid card numbers and perhaps this technique — combined with some aggregated data from other cards to help them narrow the range of cards down — would give them data that they could use to try to get transactions authorised.

This is relatively unlikely (moreover it isn’t a very “sophisticated” attack), but until we know more it must be considered a theoretically feasible attack. However, given the comments in the Times suggesting that the fraudulent transactions happened in retail stores, an attack based on generating ‘random’ valid card numbers seems highly unlikely because the chance of success of randomly generating a valid issued card number is so low, a criminal wouldn’t waste this on a cash-out-mule who puts themselves at some degree of risk by making an in-store physical transaction.

4.2 Authorisation

The Tesco Bank authorisation systems authorised transactions that they shouldn’t have. There are a few reasons this may have been so.

  1. They were not set up to properly validate the CVV2 value for an e-commerce transaction.
  2. They were not set up to properly validate the CVV for a magnetic stripe transaction.
  3. They had never been configured to recognise a magnetic-stripe-contactless transaction and so these transactions bypassed the normal authorisation route.
  4. A criminal had gained unauthorised access to the debit card authorisation system and had re-configured it to permit rather than decline these type of transactions.

5. My Hypothesis

My best guess at the moment is that the criminals secured a large batch of real Tesco Bank debit card numbers; I think it’s most probable that it came from a leak from a third party or related company. Given the number of cards used, a merchant breach (or an aggregation a number of previous breaches from merchants) seems unlikely. Additionally this does not correlate with the customers’ claims not to have ever used their cards on the Bank’s forum.

The criminals then used this data to make online and physical electromagnetic magnetic stripe emulation contactless or the US magnetic stripe contactless transactions.

But remember both a magnetic stripe transaction and an e-commerce transaction generally need more than just the account number for the transaction to complete. The magnetic stripe contactless needs the card verification value (CVV) which is encoded in the magnetic stripe and the e-commerce transaction the card verification value 2 (CVV2) which is normally printed on the reverse of the card. This data is transmitted along with the account number and expiration date to the card issuer (in the case Tesco Bank) so it can validate that the real card has been used.

So either

  • the data for the CVV and CVV2 came from the third party that would have had both the account number and these numbers – which could only be one of just a couple of Tesco Bank’s core outsourcing partners; OR
  • Tesco Bank didn’t recognise the ‘magnetic stripe contactless’ transaction type and therefore did not validate the CVV when the Bank authorised the transaction, and the criminals just submitted ‘random’ CVV values.

Given that it is currently reported that both fraudulent Magnetic Stripe and E-commerce transactions were made the only place a criminal could have got the data elements to make both those types of transaction (account number, CVV from the mag stripe and CVV2 from the back of the card) would be one of the Bank’s core processors (either the company that personalised the debit cards, or the company that authorises transactions). I’m really sceptical of a data breach at one of these two core processors (although it would be William of Occam’s preferred explanation).

My guess is that the authorisation systems at Tesco Bank, which should have spotted that these transactions were fraudulent, were either misconfigured, or were in the control of a criminal and therefore didn’t validate the CVV or CVV2 values when faced with a ‘magnetic-stripe-contactless’ transaction.

6. What action might be taken against Tesco Bank?

Some commentators have suggested that the Information Commissioner’s Office, through the Data Protection Act (and its successor the General Data Protect Regulation) would have cause to take action against Tesco Bank. The ICO is the least of Tesco Bank’s worries – even if there was a contributory breach at a third party service provider to Tesco Bank. The Bank is regulated by the Financial Conduct Authority and the Prudential Regulatory Authority (part of the Bank of England). Both bodies have the capabilities to levy unlimited fines, replace management and — in the worst case — remove Tesco’s banking license. The FCA and BoE do not like to see bank security problems on the front page of a newspaper — they are concerned about the effect that this has on the general public’s trust in the banking system. If it turns out that the fraud was enabled by a misconfiguration or criminal attack on Tesco Bank’s debit card transaction authorisation system, then their financial regulator will question whether the Bank had adequate systems and controls in place to prevent financial crime and will take the appropriate action.

Additionally, as the fraud was committed on Visa debit cards, I assume my ex-colleagues in Visa Europe will have some strong words with Tesco Bank!

Notes and sources

I’ve prepared this analysis from public news reports, statements from Tesco Bank and from information in public forums found on the Internet. My good friend and ex-colleague, Colin Whittaker of Informed Risk Decisions, helped with the analysis of the possible options.

An analysis of the T-Mobile breach

There’s been a lot in the press for the past few days about the recent T-Mobile breach. Basically it appears that a number of staff at the mobile phone company have been selling customer data which included the customer’s name, their mobile number and when their contract expired. There hasn’t been a great deal of information about this other than the BBC’s report, the Information Comissioner’s press release (PDF) and a short post on T-Mobile’s customer support forum.

From an information security and Data Protection Act compliance perspective there are three breaches of the Act.


There’s no information how the data was extracted from T-Mobile’s system and I accept that it could have been by people copying the information down onto pieces of paper, however I’ll assume that as the BBC story talked about “millions of records from thousands of customers”, there was a bulk extract of data.

T-Mobile is probably in breach of the seventh principle in that they failed to ensure:

“Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data”

It is a breach of section 4(4) of the Act if a data controller fails to comply with the data protection principles in relation to all personal data, and the Information Commissioner (for the moment) can commence enforcement proceedings against the company, in the course of which T-Mobile will have to undertake to implement better security and processes.

However what’s interesting to me is whether T-Mobile had ever properly quantified the commercial value of information about a customer’s name, mobile and contract expiration date? And if so whether this was adequately reflected in their risk analysis?

If this were the case then two technical steps I’d expect them to have taken would have been:

  1. to make it very hard for people to run and save a report that had more than (say) 20 such records (most people working in customer service wouldn’t even need this many records in a report)
  2. to implement some Data Leakage Prevention (DLP) technology that looked at the type of data moving out of the organisation in email, on removable media such as CDs, USB sticks and as physical printouts

The employee / employees

The employee(s) [the T-Mobile site now appears to indicate that it was just the action of a single employee] have committed a clear offence under Section 55(1) of the Act.

“A person must not knowingly or recklessly, without the consent of the data controller obtain or disclose personal data or the information contained in personal data”

If convicted they’ll receive a maximum of a £5,000 fine (and if the Information Commissioner gets his way then next year this could be a custodial sentence).

The data recipient

The person buying the data has also committed a Section 55 offence as they obtained the data without T-Mobile’s consent.

The identity of the person or company who purchased the data hasn’t been made public. It will be interesting to see whether it was a small phone dealer, a broker or one of the other big mobile phone companies. If the latter the there’s a real issue to explore – was this the action of a ‘rogue’ salesperson or something that was tacitly condoned by the organisation?

For a market to exist in personal data there has to be both a buyer and a seller, and the value of the data is defined by the buyer: if no one wanted to buy this information then the T-Mobile employee(s) wouldn’t have stolen it to sell. If the data was traded through a list broker then still the recipient organisation should have asked themselves where this data came from as alongside the section 55 offence they will have breached the first (be fair when you get, use and share data) and second (tell people what you will do with their data, do nothing more) data protection principles.

When this case finally comes to court I’ll be really interested to see the action taken against the purchasers of the personal data.

In the future I expect to see all databases that hold personal information equipped with full read auditing which would create an audit log entry whenever a user read an individual record, or ran a report that included that record.

Audit: User JohnDoe viewed this record at 10:23 on 22/10/09
Audit: User JaneDoe included this record in the report CustomersAboutToLeave at 19:47 on 23/10/09

I’d also expect mobile phone companies to correlate the read activity of their users (recorded in this type of audit log) against the customers who went elsewhere at the end of their contracts.