I'm not privy to any details, but a simple possibility would be to replace the destination address of any transfers initiated during the time period. You could even re-write all the DOM to hide double checks. It might have even been possible to initiate the server side request directly - but even if there was a 2FA confirmation of the transaction that included the address - I could easily see $2m worth of transfers successfully rerouted. This attack easily could have been against a bank with online wire transfers - the challenge there would be laundering the money.

I don't know much about this specific third party javascript and it's possible that tighter CSP policies could have mitigated some of the attack vectors. However, once you can MITM, it's really game over.

Before we blame usage of the js CDN, they could have performed the TLS attack on KLAYswap instead and then just reverse proxied while strategically rewriting data. It's possible that with this specific setup that the js CDN was the lowest hanging fruit.

This is such an fundamental and structural attack (BGP poisoning to screw with certificate ownership validation) that I find the comment by Phill Hallam-Baker incredulous. Perhaps there is a hobby horse against automatic certificate exchange (there is a mention on EV certs, which were such an obvious scam) or it's just a middlebrow rant about "javascript dependent pages".

There are many attacks possible with this method and plenty that will work on the simplest request/response Web 1.0 architectures.