Could certificate pinning have mitigated the damage? Although service would have been denied until the DNS was back under control, that's better than leaking credentials and cards and security questions and account balances.
It can also be used maliciously by the attackers too: they could set HPKP to their own certificates with a 5 year expiry time, then sell them to the bank after DNS is reverted. The bank might pay to have all those chrome/firefox users back.
Presumably there is a manual process to ask browser maintainers to invalidate fraudulent pins. Hell, list maintainers could charge a processing fee to ensure manual review of each case, and frequent update cycles that don't require browser restarts. The spec makes this possible but not necessary or even outlined, which I think is an oversight.
UAs MAY choose to implement additional sources of pinning
information, such as through built-in lists of pinning information.
Such UAs should allow users to override such additional sources,
including disabling them from consideration.
The effective policy for a Known Pinned Host that has both built-in
Pins and Pins from previously observed PKP header response fields is
implementation-defined.
Real time scanning certificate transparency logs (and DNS changes) would probably be a good idea as well. I don't know how much time they lost figuring out it was actually an attack. Oh, and using a domain registrar that's educated about social engineering...though I don't know that you have much choice in the matter for .com.br.
That's right, they don't have a pinning mechanism for site operators. They have something called Certificate Reputation[1] which works alongside SmartScreen and should theoretically be of use for attacks like this, but I haven't heard much about it and I don't know if it helped here.