This type of attack is not new and can simply occur from something as simple as the use of a bad password with a DNS registrar and no two-factor authentication in place. It's also important to note this is DNS redirection and not https redirection.
In a nutshell, there are two parts to this attack.
- Setting up look-alike website with valid https.
- Accessing the bank's DNS registrar account to redirect their traffic.
Note: a similar scenario could also occur if an attacker can compromise the bank's DNS servers, replacing access to the DNS registar in step 2.
Looking a little closer at Step 1 above when someone sets up a fake website they typically aim to mirror 3 things:
1A.) The look and feel of the site (easy to just download the real Html and images from the bank's real website and change the form entries to do what you want). It will be identical to what users are used to seeing and requiring almost no work on the attackers part. Note: If registering a look-a-like domain name first the attackers will likely make it look like a new bank getting a website up until the moment they launch their attack at which point they switch everything to the look-a-like site.
1B.) Optionally they can register a similar domain name. This isn't actually required at all for the attack you mentioned and since so few people look closely at their browser if SSL is established (showing green) almost any domain name would work but you could easily get a similar looking name if needed.
1C.) Register an SSL/TLS certificate for whichever domain is used in step 1B above. Again it could be for a website for notabank.com and that's a legitimate domain name to request an SSL/TLS certificate for. Alternatively, and as was the case in the situation you describe, they can simply use Lets Encrypt.
2.) For accessing the DNS registrar's account similar attacks have occurred against companies that simply used a bad password (or their companies name as the password). That being the case a simple set of brute-force attempts would give someone access to this account. Similarly, this could have been compromised by finding similar passwords used by the administrator of the bank's DNS either on another system or via a public password dump from when passwords were lost at another site. There are lots of ways someone could have lost a password here. Given most DNS registrars don't require mandatory two-factor authentication in a lot of cases just having the username and password is all one needs to access this account.
Once logged into the DNS registrar's site as the target account the attackers can literally change the DNS settings for www.bank.com to ANY IP ADDRESS IN THE WORLD. So naturally, they point it to the fake banking websites they created in step 1 above and start harvesting credentials.
If credentials are all they want they can easily grab these as people try to log in and use them to gain access to accounts one by one. More elaborate attackers or attacks against sites which implement two-factor authentication will allow the attacker to authenticate via a proxy running on the fake site which redirects the use of the logout function to a fake exit page. This allows an attacker to be authenticated by the user, including use of the end users two-factor authentication system, then gives them access to the account as soon as the unsuspecting client chooses to log out. This is more work for the attacker but it can get the attacker past two-factor authentication requirements and also will go on longer before being reported where in the case of just grabbing credentials it may appear to users that the banks' website is not working (and likely to get reported faster).
I'll also mention that there are systems in place at many banks to help detect this type of fraudulent activity and typically as soon as multiple users start authenticating from a single IP address that may warrant a security check to see if this type of attack is occurring and then action will be taken by the banks security teams to contact the ISP hosting the fraudulent site to get it taken down.
There are LOTS of other similar scenarios but this is typically how it works.
In regard to the Certificate warning. If I type www.bank.com and I get redirected to a valid website using a valid certificate why would I get any warning? Think of it as if I meant to go to www.bank.com but my browser redirected me to https://security.stackexchange.com when the browser loads the new site all it's checking for is certificate validation on the new site. The browser has no knowledge of your intentions to visit www.bank.com so if the user isn't checking the URL in the browser either bad things can happen. You can play with this yourself by setting a line in your /etc/host file (or it's equivalent) so that www.bank.com resolves to the IP of anything you want and get the same effect locally.
