{ "id": "e32af8c0-bceb-4849-b22f-00fe6b7c8dcc", "created_at": "2026-04-06T00:07:47.954501Z", "updated_at": "2026-04-10T13:11:20.47217Z", "deleted_at": null, "sha1_hash": "c438228333d35955dffb1ed04eec30c6173e6f32", "title": "The British Airways Breach: How Magecart Claimed 380,000 Victims", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1568705, "plain_text": "The British Airways Breach: How Magecart Claimed 380,000\r\nVictims\r\nPublished: 2018-09-11 · Archived: 2026-04-05 17:10:56 UTC\r\nOn September 6th, British Airways announced it had suffered a breach resulting in the theft of customer data. In\r\ninterviews with the BBC, the company noted that around 380,000 customers could have been affected and that the\r\nstolen information included personal and payment information but not passport information.\r\nOn its website, British Airways placed an article explaining details of the incident that answered as many\r\nquestions as possible for customers. The technical details were sparse but included the following pieces of\r\ninformation:\r\nPayments through its main website were affected\r\nPayments through its mobile app were affected\r\nPayments were affected from 22:58 BST August 21, 2018, until 21:45 BST September 5, 2018\r\nThe report also stated very clearly that information was stolen from the British Airways website and mobile app\r\nbut did not mention breaches of anything else, namely databases or servers—anything indicating the breach\r\naffected more than the payment information entered into the website. Because these reports only cover customer\r\ndata stolen directly from payment forms, we immediately suspected one group: Magecart.\r\nThe same type of attack happened recently when Ticketmaster UK reported a breach, after which RiskIQ found\r\nthe entire trail of the incident. Because we crawl the internet and capture the details of each page, our team was\r\nable to expand the timeline and discover more affected websites beyond what was publicly reported. In this blog,\r\nwe’ll investigate what happened during the breach of British Airways customer data made public on September 6,\r\nwhich spanned a total of 15 days according to public reporting.\r\nMagecart: A Familiar Adversary\r\nSince 2016, RiskIQ has reported on the use of web-based card skimmers operated by the threat group Magecart.\r\nTraditionally, criminals use devices known as card skimmers—devices hidden within credit card readers on\r\nATMs, fuel pumps, and other machines people pay for with credit cards every day—to steal credit card data for\r\nthe criminal to later collect and either use themselves or sell to other parties. Magecart uses a digital variety of\r\nthese devices.\r\nMagecart injects scripts designed to steal sensitive data that consumers enter into online payment forms on e-commerce websites directly or through compromised third-party suppliers used by these sites. Recently, Magecart\r\noperatives placed one of these digital skimmers on Ticketmaster websites through the compromise of a third-party\r\nfunctionality resulting in a high-profile breach of Ticketmaster customer data. Based on recent evidence, Magecart\r\nhas now set their sights on British Airways, the largest airline in the UK.\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 1 of 10\n\nFinding the Breach of British Airways\r\nOur first step in linking Magecart to the attack on British Airways was simply going through our Magecart\r\ndetection hits. Seeing instances of Magecart is so common for us that we get at least hourly alerts for websites\r\ngetting compromised with their skimmer-code. Customer notifications through our products are automated, but\r\nour research team searches for any instances outside of these workspaces manually and adds them to our global\r\nblacklists. In the case of the British Airways breach, we had no hits in our blacklist incidents or suspects because\r\nthe Magecart actors customized their skimmer in this case.\r\nOne challenge of digging through crawl data manually is the scale of the data RiskIQ collects. We crawl more\r\nthan two billion pages a day, which accumulates over time. Another is that modern websites tend to run with a lot\r\nof functionality built out in JavaScript. Just loading the main British Airways website spins up around 20 different\r\nscripts and loading the booking subpage bumps that to 30. While 30 scripts might not sound like much, many of\r\nthese are minified scripts spanning thousands of lines of script.\r\nFor this research, we decided to focus our efforts by identifying individual scripts on the British Airways website\r\nand examining their appearance over time—we would verify all the unique scripts on the website and only look at\r\nthem again if their appearance changed in our crawling. Eventually, we recorded a change in one of the scripts.\r\nOpening up the crawl, we saw this script was a modified version of the Modernizr JavaScript library, version 2.6.2\r\nto be precise. The script was loaded from the baggage claim information page on the British Airways website:\r\nFig-1 Modified script\r\nThe noted change was at the bottom of the script, a technique we often see when attackers modify JavaScript files\r\nto not break functionality. The small script tag at the bottom immediately raised our suspicions:\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 2 of 10\n\nFig-2 The suspicious script tag added by Magecart\r\nWe found more evidence in the server headers sent by the British Airways server. The servers send a ‘Last-Modified’ header, which indicates the last time a piece of static content was modified. The clean version of the\r\nModernizr script had a timestamp from December 2012:\r\nFig-3 Clean version of the compromised script\r\nWe can see on the modified, malicious version of Modernizr the timestamp matches closely to the timestamp\r\ngiven by British Airways as the beginning of people getting victimized:\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 3 of 10\n\nFig-4 Timestamp of when the skimming began\r\nHere is a cleaned up version of the script, only 22 lines of JavaScript:\r\nFig-5 Only 22 lines of script victimized 380,000 people\r\nIn essence, the script is very simple and very effective. Here is a breakdown of what it does:\r\nOnce every element on the page finishes loading it will:\r\nBind the mouseup and touchend events on a button known as submitButton with the following\r\ncallback-code:\r\nSerialize the data in a form with id paymentForm into a dictionary\r\nSerialize an item on the page with id personPaying into the same dictionary as the\r\npaymentForm information\r\nMake a text-string out of this serialized data\r\nSend the data in the form of JSON to a server hosted on baways.com\r\nOn websites, mouseup and touchend, are events for when someone lets go of the mouse after clicking on a button\r\nor when someone on a touchscreen (mobile) device lets go of the screen after pushing a button. This means that\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 4 of 10\n\nonce a user hits the button to submit their payment on the compromised British Airways site, the information from\r\nthe payment form is extracted along with their name and sent to the attacker’s server.\r\nThis attack is a simple but highly targeted approach compared to what we’ve seen in the past with the Magecart\r\nskimmer which grabbed forms indiscriminately. This particular skimmer is very much attuned to how British\r\nAirway’s payment page is set up, which tells us that the attackers carefully considered how to target this site\r\ninstead of blindly injecting the regular Magecart skimmer.\r\nThe infrastructure used in this attack was set up only with British Airways in mind and purposely targeted scripts\r\nthat would blend in with normal payment processing to avoid detection. We saw proof of this on the domain name\r\nbaways.com as well as the drop server path. The domain was hosted on 89.47.162.248 which is located in\r\nRomania and is, in fact, part of a VPS provider named Time4VPS based in Lithuania. The actors also loaded the\r\nserver with an SSL certificate. Interestingly, they decided to go with a paid certificate from Comodo instead of a\r\nfree LetsEncrypt certificate, likely to make it appear like a legitimate server:\r\nFig-6 Cert leveraged by the attackers\r\nSource: https://community.riskiq.com/search/certificate/sha1/e1a181db8f8366660840e0b490ad2da43c78205a\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 5 of 10\n\nWhat is interesting to note from the certificate the Magecart actors used is that it was issued on August 15th,\r\nwhich indicates they likely had access to the British Airways site before the reported start date of the attack on\r\nAugust 21st—possibly long before. Without visibility into its Internet-facing web assets, British Airways were not\r\nable to detect this compromise before it was too late.\r\nMobile Skimming\r\nIn the security advisory from British Airways, the company made note that both the web app and the mobile app\r\nusers were affected. We found the skimmer on the webpage for British Airways, but how does that translate to\r\nmobile? To figure this out we’ll look at the British Airways Android application:\r\nFig-7 British Airways mobile application\r\nOften, when developers build a mobile app, they make an empty shell and load content from elsewhere. In the\r\ncase of British Airways, a portion of the app is native but the majority of its functionality loads from web pages\r\nfrom the official British Airways website.\r\nThe mobile app uses a set of different hosts to communicate back to the British Airways servers:\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 6 of 10\n\nwww.britishairways.com (The main website)\r\napi4-prl.baplc.com (An API endpoint from British Airways)\r\napi4.baplc.com (Another API endpoint from British Airways)\r\nThe idea is that for quick data updates on its UI the app uses the API endpoints, but for searching, booking, and\r\nmanaging flights the app loads a mobile version of the main website. One of these called-up paths is:\r\nwww.britishairways.com/travel/ba_vsg17.jsp/seccharge/public/en_gb\r\nThis page is loaded when the customer requests information about fees for different countries and airports. It looks\r\nlike this:\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 7 of 10\n\nFig-8 Magecart-compromised mobile web page\r\nNow, if we look at the source of this webpage we find something interesting—the page is built with the same CSS\r\nand JavaScript components as the real website, meaning design and functionality-wise, it’s a total match. From\r\nwhat we examined above, we know that this means we’ll also find our offending script—the one that steals name\r\nand payment information from the web app—on the mobile app:\r\nFig-9 Source of the mobile web page\r\nOur crawler captured the subresource being loaded by the page used in the mobile app; it loads the same (at the\r\ntime) compromised Modernizr JavaScript library!\r\nOne thing to note is that the magecart actor(s) put in the touchend callback in the skimmer to make it work for\r\nmobile visitors as well, which again shows us the high level of planning and attention to detail displayed in this\r\nsimple yet extremely effective attack.\r\nConclusions\r\nAs we’ve seen in this attack, Magecart set up custom, targeted infrastructure to blend in with the British Airways\r\nwebsite specifically and avoid detection for as long as possible. While we can never know how much reach the\r\nattackers had on the British Airways servers, the fact that they were able to modify a resource for the site tells us\r\nthe access was substantial, and the fact they likely had access long before the attack even started is a stark\r\nreminder about the vulnerability of web-facing assets\r\nRiskIQ has been warning the market about Magecart attacks like this since 2015 and will continue to follow and\r\nreport on the group as it evolves. While the Magecart attack against British Airways wasn’t a compromise of a\r\nthird-party supplier like the attack on Ticketmaster, it does raise the question of payment form security.\r\nCompanies, especially those that collect sensitive financial data, must realize that they should consider the\r\nsecurity of their forms—but also the controls that influence what happens to payment information once a customer\r\nsubmits it.\r\nWe suggest British Airways customers get a new card from their bank. Some banks have already been proactively\r\nissuing new cards for their customers, Monzo is an example of these:\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 8 of 10\n\nFig-10 How some banks are responding\r\nSource: https://twitter.com/monzo/status/1038042015286607872\r\nMagecart is an active threat that operates at a scale and breadth that rivals—or possibly surpasses—the recent\r\ncompromises of point-of-sale systems of retail giants such as Home Depot and Target. The Magecart actors have\r\nbeen active since 2015 and have never retreated from their chosen criminal activity. Instead, they have continually\r\nrefined their tactics and targets to maximize the return on their efforts.\r\nOver time, they’ve optimized their tactics culminating in successful breaches of third-party providers such as\r\nInbenta resulting in the theft of Ticketmaster customer data. We’re now seeing them target specific brands,\r\ncrafting their attacks to match the functionality of specific sites, which we saw in the breach of British Airways.\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 9 of 10\n\nThere will be more Magecart attacks, and RiskIQ will be tracking them and keeping the cybersecurity industry\r\naware of our research.\r\nFor a deep dive on Magecart, from the group’s inception to its hack of Ticketmaster to its latest hack of British\r\nAirways, be sure to register for the webinar hosted by RiskIQ Head Researcher and report author Yonathan\r\nKlijnsma.\r\nSource: https://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nhttps://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://web.archive.org/web/20181231220607/https://riskiq.com/blog/labs/magecart-british-airways-breach/" ], "report_names": [ "magecart-british-airways-breach" ], "threat_actors": [ { "id": "5a0483f5-09b3-4673-bb5a-56d41eaf91ed", "created_at": "2023-01-06T13:46:38.814104Z", "updated_at": "2026-04-10T02:00:03.110104Z", "deleted_at": null, "main_name": "MageCart", "aliases": [], "source_name": "MISPGALAXY:MageCart", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "77b28afd-8187-4917-a453-1d5a279cb5e4", "created_at": "2022-10-25T15:50:23.768278Z", "updated_at": "2026-04-10T02:00:05.266635Z", "deleted_at": null, "main_name": "Inception", "aliases": [ "Inception Framework", "Cloud Atlas" ], "source_name": "MITRE:Inception", "tools": [ "PowerShower", "VBShower", "LaZagne" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434067, "ts_updated_at": 1775826680, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c438228333d35955dffb1ed04eec30c6173e6f32.pdf", "text": "https://archive.orkl.eu/c438228333d35955dffb1ed04eec30c6173e6f32.txt", "img": "https://archive.orkl.eu/c438228333d35955dffb1ed04eec30c6173e6f32.jpg" } }