The interesting thing about Incident Response, and the Discipline of Digital Forensics is the need to attempt to backtrack on 1) How a security breach occurred? 2) What Actors were in play? And 3) Where any vulnerabilities or points of exposure present which supported the breach to play? – or more the point, do they still exist?
In the case of the recent Tesco Bank Breach, I am expectant that a Major Incident Review [MIR] was put in full swing post incident to work out just what exposure(s) allowed such an expansive on-mass breach of multiplications of customer accounts, manifesting in the illicit transfer of funds into the pockets of criminality. And let us not forget that it was only in February 2016 when Tesco also suffered a reported breach involving the compromise of credit card and banking details of its customers.
Now clearly in my case I only have access to information which is residing within the view of the public – along with the employment of some OSINT [Open Source Intelligence] discovery missions. However, I would like to offer a possible theory as to how this, and other such successful breaches did, or may have occurred.
So, based on the known knowns about the bank, a little OSINT digging soon located several points of intelligence on the web which verbosely outline how this leading edge bank is seeking cost reductions, applying the approach of outsourcing, with over £60 million spent in 2016 on such Third-Party support. So, at this stage we can deduce that there is a high probability that some of their Banking Platforms are sitting upon such technological support – some of which may not be under the direct control of the Bank. Second discovery of interest. One of the documents published by Tesco commented on the banking platform of choice the bank had chosen to run it operations. So here we have yet another lead to test the theory.
The next step in our discovery mission was to check out the actual banking platform in use, and the associated supporting organisation which was inferred to support Tesco – and as if by magic, there it was – this very company (Platform) had been reported to have suffered from a Heartbleed vulnerability!
My external theory here is it is a probability that:
- Client credentials and sensitive information could have been harvested over a period of opportunity
- There is of course the related probability that of the multiples of millions of other security breached accounts which have occurred in the last 12 months played a part. Some of which also suffered from the Heartbleed exposure, and may have also allowed unauthorised access to sensitive objects which may have been leveraged
- That a well-planned, offline Project was put in place to identify, extract, and to feed into the attack stream the compromised credentials to be invoked
- That the attack plan included a well built, automated mechanism to maximise the point-and-click data entry replay
- The inbuilt thresholds to extract funds were kept at a sensible level, so as not to tempt raising any alarms [imagine multiples of alerts being generated by an overzealous transfer requests]
- The weekend was chosen for two reasons 1) It is a time when staffing levels are lower than the normal operational week, and 2) The weekend period would most likely offer up the camouflage of maximised end-user activity against their legitimate bank account
Of course, this is only a theory based on some facts I have discovered, However, I, my family members who have an account with Tesco, and no doubt all the other multiples of unfortunates who suffered loss would no doubt welcome an explanation as to just how this breach did occur.
To close – you may have noticed from breaches going back over 30 years, from the well documented Cuckoo’s Egg attack [Clifford Stoll] up to some more recent well documented breaches, Third Parties and their Platforms have played their part as the hackers back-door to the associated crown jewels. This why if you do utilise Third Parity support, it is so very important to proactively manage that relationship.