The RiskIQ blog explaining their analysis of the giant BA breach, by scanning public domain information, is excellent and in-depth. Here’s the executive summary, five things you need to know, because several people have been asking me for this.

1) Small custom changes bypassed the usual monitoring and alarms:

…Magecart is so common for us that we get at least hourly alerts for websites getting compromised with their skimmer-code…[yet with BA] we had no hits in our blacklist incidents or suspects because the Magecart actors customized their skimmer in this case.

2) Thus, finding the attack meant looking for a different change, which turned out to be in the baggage claim code:

…we would verify all the unique scripts on the website and only look at them again if their appearance changed in our crawling. Eventually, we recorded a change in one of the scripts. Opening up the crawl, we saw this script was a modified version of the Modernizr JavaScript library, version 2.6.2…

3) Attackers became so familiar with their targeted environment they used several layers of obfuscation down to the infrastructure level:

The infrastructure used in this attack was set up only with British Airways in mind and purposely targeted scripts that would blend in with normal payment processing to avoid detection. We saw proof of this on the domain name baways.com as well as the drop server path. The domain was hosted on 89.47.162.248 which is located in Romania and is, in fact, part of a VPS provider named Time4VPS based in Lithuania. The actors also loaded the server with an SSL certificate. Interestingly, they decided to go with a paid certificate from Comodo instead of a free LetsEncrypt certificate, likely to make it appear like a legitimate server

4) Changes to the script were minimal and leveraged existing business logic to fit in, just enough to redirect payment information:

On websites, mouseup and touchend, are events for when someone lets go of the mouse after clicking on a button or when someone on a touchscreen (mobile) device lets go of the screen after pushing a button. This means that once a user hits the button to submit their payment on the compromised British Airways site, the information from the payment form is extracted along with their name and sent to the attacker’s server.

5) Ability to change a script leaves open the question of privileged access management, and how contained the attacks are:

…the fact that they were able to modify a resource for the site tells us the access was substantial…British Airways wasn’t a compromise of a third-party supplier like the attack on Ticketmaster, it does raise the question of payment form security…

Kudos to RiskIQ for providing a dump of their data collection and analysis of what changed in the scripts.

In summary, this example of a blacklist failing is a very good case for why whitelists are better. Had British Airways been monitoring their payment script for changes (2012 script modified in 2018, to look like a script from 2012) and used cryptographic signatures, they would have been able to detect this attack. No blacklist is going to find a business process attack designed to look like the business process, unless exceptionally lucky, once a privilege escalation has occurred (essentially an impostor scenario). At that point change control and alerting is the last and best line of defense.