CyphrQ
Menu

British Airways Data Breach Fine: What Happened and Why It Cost £20m

How attackers skimmed British Airways card data in 2018, why the ICO fined £20m not £183.39m, and the controls the ICO says were missing.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: June 201812 min read

The British Airways data breach fine was £20 million, set by the UK Information Commissioner's Office (ICO) on 16 October 2020. In 2018 an attacker used a supplier's login to get into BA's network, found an administrator password in a plain text file, and changed a script on britishairways.com so card details were copied as customers typed them. About 429,612 people were affected.

The ICO first proposed £183.39 million. Every figure below comes from the ICO's own penalty notice, with paragraph numbers so you can check it.

Case file

Field Detail
Organisation British Airways plc
Region UK; affected customers in the UK, the EU and the rest of the world
Breach date 22 June to 5 September 2018 (card skimming live 21 August to 5 September 2018)
Disclosed 6 September 2018, to the ICO, banks, payment schemes and 496,636 customers
People affected Approximately 429,612
Data types Names, addresses, card numbers, CVV numbers; staff and administrator usernames and passwords; Executive Club usernames and PINs
Penalty £20m (proposed £183.39m in July 2019)
Regulator UK Information Commissioner's Office, acting as lead supervisory authority under the GDPR
Status Final penalty notice issued 16 October 2020

Source for every row: the ICO penalty notice, paras 1.2, 1.3, 1.7, 1.8, 3.25, 3.27, 4.1 and 5.3.

What happened at British Airways, and when?

On 22 June 2018, an attacker who has never been identified got into BA's IT systems. The attacker kept that access, undetected, until 5 September 2018 (ICO penalty notice, para 3.4).

The key dates, all from the notice:

  • 22 June 2018: first access, through BA's Citrix remote access gateway (paras 3.4 to 3.5).
  • 23 to 25 June 2018: three failed logins with a System Administrator account, then successful logins to three servers (para 3.18).
  • 26 July 2018: the attacker reached log files holding card details from BA redemption bookings in plain text (para 3.21).
  • 14 to 25 August 2018: the attacker changed code on BA's website to send card data to BAways.com, a domain the attacker owned (para 3.25).
  • 21 August to 5 September 2018: the changed code was live for 15 days. Each time a customer entered card details, a copy went to the attacker and the booking carried on as normal (para 3.25).
  • 5 September 2018: a third party told BA that data was going from britishairways.com to BAways.com. BA contained it within 90 minutes and blocked the paths to BAways.com 20 minutes later (para 3.26).
  • 6 September 2018: BA notified the ICO, acquiring banks, payment schemes and 496,636 customers. On 7 September it notified another 39,480 customers (para 3.27).

BA did not find the attack itself. The ICO called this especially serious, because it was "unclear whether or when BA itself would ever have detected the breach" (para 7.10).

What British Airways customer data was taken, and from how many people?

The ICO says the attacker potentially accessed the personal data of approximately 429,612 people (para 4.1):

Data exposed People
Name, address, card number and CVV 244,000
Card number and CVV only 77,000
Card number only 108,000
Executive Club usernames and PINs Up to 612
Usernames and passwords of BA staff and administrator accounts Not counted in the notice

The 108,000 card numbers came from a separate failure. A testing feature that logged card details, including CVVs in most cases, was left switched on when the system went live. It had been logging card data unnecessarily since December 2015. The logs were kept for 95 days, which limited how much was there (para 3.22).

The ICO treated the card data as particularly serious, because names, addresses and unencrypted card details together allow "the opportunity for identity theft" (para 7.32). More than 40,000 people took up BA's offer of free credit monitoring (para 7.12).

How did the British Airways attackers get in?

The ICO's notice breaks the attack into eight steps, some of them redacted. The key ones show a chain of ordinary weaknesses rather than one clever trick.

  1. A supplier's password, with no second factor. The attacker used login details BA had issued to a Swissport employee based in Trinidad and Tobago. Swissport supplied cargo services to BA. BA never found out how the details were stolen. The account had no multi-factor authentication (MFA): a password alone opened the gateway (paras 3.6 to 3.7).
  2. Breaking out of Citrix. Swissport staff were meant to reach only a small set of applications. The attacker got out of that restricted environment into BA's wider network, brought in tools from outside, and mapped the network (paras 3.9 to 3.14).
  3. An admin password in a text file. During that mapping, the attacker found the username and password of a privileged domain administrator account stored in plain text. In theory, any user in that domain could have opened the file (para 3.15).
  4. More stored credentials and an enabled Guest account. The attacker found a database System Administrator password, then switched on a disabled Guest account and added it to a local administrators group (paras 3.17, 6.75).
  5. Card logs. The attacker found and accessed the plain text card logs described above (para 3.21).
  6. The skimming script. Finally, the attacker found the files holding the website's code and edited a JavaScript file so card data entered on britishairways.com was copied to BAways.com (paras 1.2, 3.24 to 3.25).

That last step is what the card industry calls e-skimming or web skimming: malicious code on a payment page that copies what you type and sends it elsewhere, while the page still works normally (PCI SSC). The ICO's notice does not name a criminal group, so neither do we.

What was the British Airways data breach fine, and why did it drop from £183m to £20m?

The final penalty was £20 million, for failing to keep personal data secure under Articles 5(1)(f) and 32 of the GDPR (paras 1.6 to 1.7). The ICO found BA negligent, though not deliberate (paras 7.18 to 7.19). BA did not admit liability (para 1.6).

On 4 July 2019, the ICO had issued a notice of intent proposing £183.39 million (para 5.3). Four things explain the gap, all in the ICO's own words:

  • A different method. The first figure relied on a draft internal procedure that set penalties by bands of company turnover. After BA objected, the ICO agreed not to use it in this case (paras 7.60 to 7.62). The ICO says the final figure was not calculated by cutting the old one (para 7.64).
  • New facts. BA sent detailed representations in September 2019 and January 2020, including a new account of how the attack happened (paras 3.2, 5.8).
  • Mitigation. BA notified quickly, cooperated fully, offered to reimburse customers' financial losses and improved its security. The ICO cut its starting figure by 20% for these (paras 7.41 to 7.47).
  • Covid-19. The ICO said the fine would not cause BA financial hardship, but applied its published pandemic policy and took off a further £4 million (paras 7.49 to 7.53).

The arithmetic, as the notice sets it out:

Step Amount
Starting figure for the seriousness of the breach £30m (para 7.36)
Aggravating factors, deterrence No change (paras 7.37 to 7.39)
Mitigating factors, minus 20% £24m (para 7.47)
Covid-19 reduction, minus £4m £20m (para 7.53)

For scale: BA confirmed worldwide turnover of £12,226,000,000 for 2017 (para 7.55). £20 million is about 0.16% of that, against a GDPR maximum of 4% for this kind of infringement (paras 2.15, 7.54).

What changed afterwards for British Airways?

The notice records these changes at BA (others in para 7.46 are redacted):

  • MFA on all remote access accounts (para 3.7).
  • Tighter Group Policy to block the tools the attacker used inside Citrix (paras 3.11, 6.51).
  • Endpoint detection and response: CrowdStrike Falcon was fully deployed by 16 November 2018 (paras 3.29, 7.14).
  • Customer remedies: an offer, made on 7 September 2018, to reimburse financial losses from stolen card details, plus free credit monitoring (para 7.44).
  • Security budget: BA told the ICO it would not cut IT security spending because of Covid-19 (para 7.46).

The wider change came from the card industry. PCI DSS v4.0 added two requirements aimed squarely at web skimming, 6.4.3 and 11.6.1. Both were best practice until 31 March 2025 and are now required (PCI SSC, SAQ A v4.0).

Going deeper: for security and IT teams

The threat model is a financially motivated intruder with patience: 60 days between first access and the skimmer going live (paras 3.4, 3.25). The attacker needed one valid third-party credential, a weak boundary inside a remote access environment, and stored secrets. The prize was card data captured in the customer's browser, before any server-side protection applied.

British Airways attack chain in ATT&CK terms

Step (ICO notice) ATT&CK technique
Swissport credentials used on the Citrix Access Gateway T1133 External Remote Services, T1078 Valid Accounts
Domain admin and SA passwords found in files T1552.001 Unsecured Credentials: Credentials In Files
Disabled Guest account enabled and added to local admins T1078.001 Valid Accounts: Default Accounts, T1098 Account Manipulation
JavaScript on britishairways.com edited to copy card data Closest fit: T1056.003 Input Capture: Web Portal Capture

Two caveats. ATT&CK describes T1056.003 in terms of credentials on login portals, not payment forms, so treat that mapping as approximate. And we have not assigned IDs to the Citrix breakout or the reconnaissance, because the notice redacts how they were done. ATT&CK's T1133 page lists M1032 Multi-factor Authentication among its mitigations, which is exactly the control missing at step one.

The control failures the ICO lists

  • MFA and remote access. BA's own Network Access Control Policy of 7 October 2017 required MFA for all remote network access, including third parties. Of 243 applications on the Citrix gateway, 13 were not protected by MFA. The ICO said MFA, external IP allowlisting or an IPsec VPN would each have been appropriate (paras 6.17 to 6.20).
  • Least privilege and hardening. Application allowlisting with built-in Windows tools such as Software Restriction Policies and AppLocker, blocklists, or server hardening (paras 6.41 to 6.44, footnote 46).
  • Testing scope. No internal, credentialed penetration test simulating an attacker already on the network (paras 6.56, 6.66).
  • Hardcoded credentials. Storing a domain admin password in plain text was not acceptable, whatever the operational reason (paras 6.57, 6.74).
  • Privileged account monitoring. Nothing alerted on failed System Administrator logins or on the Guest account joining a local admin group. The ICO suggested a privileged access management tool (paras 6.77 to 6.78).
  • Logging. BA was not generating or monitoring logs at a level that would catch these actions (para 6.84).
  • Data minimisation and code review. Debug card logging survived go-live. The ICO cited PCI DSS requirement 3.1 on keeping cardholder data storage to a minimum, and noted that CVVs should never have been logged (paras 6.88 to 6.91).
  • File integrity monitoring. BA had manual change control but no technical way to detect an unauthorised change to its website code. The ICO cited PCI DSS v3.2.1 requirements 10.5.5 and 11.5 (paras 6.92 to 6.94).

Script integrity on payment pages: PCI DSS 6.4.3 and 11.6.1

Requirement 6.4.3 covers every payment page script loaded and executed in the consumer's browser. You need a method to confirm each script is authorised, a method to assure each script's integrity, and an inventory with a written justification for each script. It applies to first-, third- and fourth-party scripts.

Requirement 11.6.1 needs a change- and tamper-detection mechanism that alerts on unauthorised changes to the HTTP headers and contents of payment pages as received by the consumer's browser. It must run at least once every seven days, or at a frequency set by a targeted risk analysis (PCI SSC, SAQ A v4.0). The Council has published an information supplement on meeting both requirements (PCI SSC blog).

Two browser features help here:

  • Subresource Integrity (SRI) puts a cryptographic hash in the integrity attribute of a <script> tag. If the file served doesn't match, the browser refuses to run it. It suits static, versioned scripts. On its own it would not have saved BA: an attacker who can edit the server's JavaScript may also be able to edit the HTML that carries the hash.
  • Content Security Policy (CSP) is a response header that lists which sources may serve scripts (script-src) and where the page may send data (connect-src, form-action). A tight policy would have blocked requests to an unknown domain such as BAways.com, unless the attacker could also change the header. That is why 11.6.1 monitors headers as well as content.

Detection signals

  • New outbound requests from payment pages to domains not in your inventory, especially look-alikes of your brand. BA's tip-off was POST requests to BAways.com (para 3.26, footnote 20).
  • A change to the hash of any script loaded on checkout pages outside an approved release.
  • Failed logins on dormant or built-in administrator accounts (para 3.18).
  • A disabled account being re-enabled, or any account added to a local or domain admin group (para 6.77).
  • Files containing cleartext card numbers or CVVs anywhere outside the payment flow.

What to check in your own estate

  • List every remote access route, including supplier and support accounts, and confirm MFA on each one. Ask for evidence, not a policy document.
  • Search file shares, scripts and configuration files for stored passwords, starting with admin accounts.
  • Test whether a low-privilege remote user can break out of your virtual desktop or Citrix environment. Make it part of your next internal penetration test.
  • Confirm alerts fire when a disabled or built-in account is enabled or joins an admin group. Test it on a non-production machine.
  • Build the 6.4.3 script inventory for every payment page, and check that your 11.6.1 monitoring reads headers and content as the browser receives them.
  • Search your logs for card numbers and CVVs.

Questions for vendors: does your payment page provider or tag manager let anyone change scripts on your checkout without your release process? Who is alerted when a script changes, and how fast?

Key takeaways

  • The ICO fined British Airways £20 million in October 2020, down from a proposed £183.39 million.
  • About 429,612 people were affected, including 244,000 with names, addresses, card numbers and CVVs exposed.
  • The attack began with a supplier's password on a remote access gateway with no MFA, even though BA's own policy required it.
  • A plain text admin password and missing monitoring let the attacker stay in for 75 days, until a third party spotted the skimmer.
  • The fine fell because the ICO changed its method, heard new facts, credited BA's response, and applied a Covid-19 reduction.
  • PCI DSS 6.4.3 and 11.6.1 now require script control and tamper detection on payment pages.

Sources