The British Airways Incident

In 2019, British Airways was notified that they were facing a record £183 million fine from the UK Information Commissioner’s (ICO) based on their loss of 380,000 individuals’ credit and debit card details. The fine was reduced to £19.8 million in October 2020, not because BA wasn’t at fault, but because they were devastated by the COVID-19 pandemic. However, the fine won’t be their biggest cost: they’re now facing group legal actions from law firms representing affected customers, with total claims reach £800 million ($1.09 :billion) or more – an astoundingly expensive incident.

The responsibility for this loss of data lies squarely with BA. They have a complex, global environment with long-standing issues around access control and maintenance, and they were slow to patch critical utilities on their payment sites. But it’s worth noting that they were the victims of a sophisticated operation that takes advantage of payment sites’ dependencies on third-party code and services, and against which defenses have been limited – a type of attack referred to as “MageCart.”

What Magecart did to BA

The term Magecart is popularly used both for the groups of cybercriminals who target online shopping cart systems to steal users’ payment card information using a specific type of attack and for the attack they use. The technical term for what they’re doing is “web skimming” or “formjacking,” and it involves inserting malicious code onto a website to steal a copy of the information a user enters into an online payment form. It’s analogous to the use of physical card skimmers on gas pumps and ATMs. If done correctly, neither the user nor the site suspects it is happening. The Magecart groups have been very successful and continue to be active; BA was not the first company to fall victim to them.

The Magecart operators gained access to BA’s internal network by compromising an account used by an employee of a cargo handling company in Trinidad and Tobago, which was relatively easy to do since BA wasn’t requiring its suppliers to use multi-factor authentication. Once they had that access, they moved laterally within BA’s network, eventually obtaining the ability to edit the payment page on BA’s public-facing website. They then altered 22 lines of JavaScript code in a library called Modernizr so, when a user enters information on the form, a copy would be sent to their server (“”) as well as to BA’s databases. Because BA’s mobile application mirrors its main website, this code change propagated to the mobile application too. From that point forward, anyone who used BA’s online payment forms had their data stolen.

The Aftermath

Once the breach came to light, British Airways reported it to their customers and fixed it. They also reported it to the UK ICO, because their failure to protect personal data was a potential GDPR violation – and an expensive one as we’ve seen, in terms of brand damage, fines, and upcoming settlement payouts.

But… could all of this have been prevented? BA absolutely should certainly have had better access control safeguards in place, but a dedicated group focused on a specific target may eventually find a way in. They also failed to update Modernizr, which had a known vulnerability. Magecart is a sophisticated set of attackers, though, and if that specific vulnerability hadn’t been present, they might well have found another. However – if there were a way for BA to instantly detect the intruders’ change to their JavaScript code, and rapidly spot the fact that data was being redirected to a suspicious third-party server, this would have stopped the attack cold.

Lokker™ Privacy Control solution could have helped prevent catastrophe.

Lokker™ would have detected the attack at two points. First, it would have noticed Magecart’s changes to Modernizr’s Javascript and reported it. Second, it would have recognized that the code was intended to send data outside the company to a new destination. The domain was newly-created, and while it was too new to be on lists of bad domains, the mere fact that it was new would have caused Lokker™ to send BA an alert. Depending on how Lokker™ is configured, it can either notify you that the change has occurred and let you decide what to do about it, or spot a problem, cut off the data flow, and then alert you that it’s done so. In the case of this attack, automatically cutting off that flow wouldn’t necessarily have even taken the payments website offline, as the Magecart crew was siphoning off a copy of the data while leaving the payment function intact.

There are other ways to spot this kind of hostile activity, but Lokker™, since it’s an active monitoring solution, watches for suspicious changes continuously. This matters because a sophisticated attacker – and the group that hit British Airways was sophisticated – may only interfere with some transactions, or may be able to spot routine scans and avoid showing itself to them. Lokker™ filters all transactions, all the time and can catch those attackers even if they’re clever. Had it been available to them at the time, BA could have detected this attack early and been able to shut it down fast – maybe even before any personal data got out. This would have drastically reduced the fine, even if they still would have had to report the intrusion itself.