How attackers bypass the new two-factor ID and how to protect your users

Preparing the attack

To execute the attack we will use a combination of two tools, Muraena and Necrobrowser. Muraena is a
reverse proxy
that will run our phishing page. The phishing page will be the original page that the victim will interact with. Once the victim has authenticated to the session, Muraena will hand over the session to Necrobrowser, allowing the attacker to take control of the session or automate the next steps of the attack. Because Muraena acts as a reverse proxy, there will be no difference between our malicious site and the original website, apart from the URL. Muraena can be configured to use SSL with certificates obtained through, for example, LetsEncrypt. From the victim’s point of view, the whole experience will seem legitimate, as it simulates interacting with the original page. They will go through the regular authentication process, including 2FA. If the 2FA consists of a regular one-time password (OTP) sent by SMS, hardware token or software, then the victim will enter it as usual. However, even modern methods, such as an automatic notification to a mobile device or scanning a QR code on the screen, will be ignored by this attack.

1. The user visits the phishing page, which has SSL enabled.
2. The reverse proxy (Muraena) looks for the legitimate banking page and delivers a copy to the victim.
3. The victim attempts to log in to the page and is prompted for two-factor authentication.
4. After the victim has completed the authentication process, the reverse proxy (Muraena) hands over the session to the attacker (Necrobrowser) to take control, cutting off the victim.

In the image below you can see Muraena hosting Google on the phish.anti domain. For demonstration purposes, a local DNS will be configured to resolve this on your test machine and also issue certificates using your own CA, which the browser trusts. However, this is exactly what it would look like from the victim’s perspective if it were implemented on your own domain using valid certificates.

Protecting against attack

Now that we understand how the attack works, we can identify what steps would be necessary to identify or protect against this type of attack.

The dynamic link provides a good first layer of defense against a variety of attacks. Dynamic linking consists of two-factor authentication performed at the time of the transaction, which incorporates the transaction details into the signing process; often referred to as What you see is what you signbecause the end user must receive the details of the transaction before completing the signing process. Once signed, the signature should only be valid for this specific transaction, making it more difficult for the attacker to bypass. Typically, dynamic linking is implemented through hardware tokens, software tokens or integrated as part of a banking application. Below, we have two examples of dynamic links, first for a legitimate payment and the second when an attacker tries to modify the payment.

1. The user creates a transaction in online banking.
2. The user sends the transaction.
3. The bank sends the transaction details to the user’s cell phone.
4. The user verifies the transfer details and authorizes the payment with biometrics (or other second factor).
5. The mobile application generates a one-time password (OTP) using the transaction details and token key within the mobile application.

1. The user attempts to make a payment in online banking.
2. The attacker modifies the payment to have a new account and/or amount of money.
3. The bank sends the transaction details to the user’s cell phone.
4. The user is presented with the modified payment information and rejects the payment.

The above examples also illustrate the importance of using end-to-end encryption when implementing dynamic linking. In addition, it shows that the mobile application itself must be protected, as the attacker may try to attack the application to hide the user’s modified payment details.

Another effective way to recognize and defend against a wide variety of attacks is to implement continuous monitoring on your digital platforms. By monitoring the session from the time of login to the end of the session, we can better put into context those actions of users and the devices or accounts with which they are associated. Continuous monitoring combines perfectly with other layers, such as 2FA or dynamic links, as they also allow the bank to put itself in context from these authentication devices.

The bank can then monitor typical indicators of known attacks, such as new devices, locations, proxy presence or others. This information can be correlated across your user base to better understand the risk of these items. Then we can also take into account the operations that the user is performing during the whole session and compare this with his usual behavior. This approach establishes a continuous risk profile for the session that can change with each action taken by the end user. This not only allows the bank to take automated actions in real time when anomalies are detected, but also allows the bank to reduce friction for legitimate sessions by reducing the number of authentications required for real sessions.

Conclusion

While the attack in this article talks about technology and concepts that have been around for centuries, we see that applying them correctly can still lead to great success and fight against various authentication methods implemented today. It is important for banks to use a layered approach, as most of the individual layers can be attacked or dynamited. When implementing dynamic links, banks must ensure that they establish a secure line of communication with the end user. For example, trusting an SMS is no longer reliable, since messages can be stolen, forged or intercepted by the attacker. However, when implementing mobile applications, banks must also be aware that these applications become a target and must protect their mobile applications from external attacks. The goal of this article is primarily to demonstrate that phishing attacks can be modernized to defeat two-factor authentication at login and implementing 2FA alone does not provide complete protection against phishing. Finally, we have mentioned some layers that banks can implement to provide greater protection to their end users, as well as what pitfalls to avoid in doing so. To summarize:

• It implements dynamic links with end-to-end encryption.
• Implements server-side analytics to monitor end-user sessions, devices and behavior in the face of potential attacks.
• Protect your mobile applications from malware and other external threats.