Basic MFA is Not Protecting You from Phishing
Multifactor authentication prompt from Microsoft's Authenticator mobile app
A false sense of security
In the ongoing battle against cyber threats, many organizations have turned to multi-factor authentication (MFA) as a silver bullet for securing their systems. The most common approach is implementing Time-Based One-Time Passwords (TOTP), where users receive a temporary passcode via SMS or phone app to access their accounts. Alongside this, companies often invest in phishing training, hoping to educate employees about the dangers of malicious emails and websites.
However, these efforts often create a false sense of security. Relying on TOTP and basic phishing training is no longer sufficient, as modern phishing attacks have become increasingly sophisticated. These advanced techniques can easily bypass TOTP and trick even well-trained employees, leaving organizations exposed to significant vulnerabilities despite their attempts to bolster security.
A modern phishing scenario
Despite implementing TOTP MFA and providing engaging training on the intricacies of detecting a phishing email, it is inevitable that a user is careless, or hasn't had adequate exposure to real phishing, and clicks a link on a maliciously crafted message. From here, any number of things can follow - from a malicious binary download to a XSS attack. When it comes to handling a phished user, the world is an attacker's oyster.
However, in recent years, a more insidious chain of events that can happen is that the victim is led to a seemingly innocuous login page, convincingly identical to their corporate authentication portal. Often, attackers will register domains that are almost identical to the real login page and will completely mimic the actual login page, including images and styling:
Notice the missing "t" in microsofonline[dot]com.
After scanning the URL and becoming satisfied with their quick pass, the victim then notices that the authentication portal itself matches what is seen every day during their authentication. The background shares the same image and the form itself has all the right colors and shapes. When the victim types in their username, it presents the same loading animation. The site then verifies the username and the victim is presented with a password prompt.
From here, they input their password and submit, knowing that they at least have one more credential to provide if they are to proceed to the destination. Finally, the site validates the credentials and presents a prompt to input the code provided by the victim's MFA mechanism. Perhaps less guarded, the victim inputs the random 6-digit TOTP from their phone app and hits enter (after all, a randomly generated token can be captured without fear, as it will generate a new code seconds later).
Following this, the victim is routed to their actual authentication portal, which prompts them yet again to log in. Confused, the victim simply logs in again, assuming it's just a computer being a computer.
The adversary in the middle
Unfortunately, the victim fell prey to a proxy-based, session hijack. The credentials typed into the authentication prompt were captured by a server sitting between the victim and the actual target authentication site. The captured credentials, while potentially useful, weren't captured for the attacker's future use. Rather, they were immediately forwarded to the actual authentication server behind the scenes. The responses from the real server were then captured again by the proxy, and then the victim was presented with a re-rendered version of the process (username/password/token). It can even handle invalid credentials, prompting the victim with the appropriate error messaging.
Once the MFA code is captured and forwarded to the true authentication endpoint, the actual login portal responds with a session token. This token is basically a ticket to the victim's account - no credentials needed. The attacker simply needs to go to the site for which the authentication was happening and inject their newly acquired token into a cookie. Once they hit Refresh, the site validates the token and lets them in under the victim's account.
To make matters worse, the means to do this exists in freely available, open-source projects. One such example is Evilginx. This application can be downloaded and implemented in less than ten minutes and handles most every part of the adversary-in-the-middle attack automatically. An attacker simply needs to register a domain, stand up Evilginx, craft their malicious email, and send it to their target. Evilginx will handle the credential passthrough to the actual authentication portal and will even clone the portal’s page style to be truly convincing:
So, in a world where multiple factors of authentication isn't enough to protect against attacks like this, how can users be protected, short of absolute diligence with investigating the details presented on their screens? After all, the human element has a cap on effectiveness, with regards to securing data.
A real defense
The answer lies within specific technical controls that can be implemented to reduce, or even eliminate, any real likelihood of a phishing attack succeeding.
If you're wanting the strongest defense against phishing attacks, look no further than passkeys. Passkeys stand as a complete replacement for passwords and are actually the way to achieve passwordless environments. The idea behind the design of passkeys is to fix the issue of passwords being a hassle to remember, leading to simpler passwords that are easy to brute force. But passkeys also have the advantage of being bound to specific resources using cryptographic key pairs and will only authenticate when it recognizes the resource in the request. The key pairs are unique to every online resource registered to the passkey authenticator and any information about how the user is authenticating locally (e.g. biometrics) never leaves the local device.
To put it in a simpler way, passkeys wouldn't have authenticated the previously mentioned victim when they were prompted at acme-solutiions.com/login. Instead, it would only respond with the appropriate secret when requested by acme-solutions.com/login and only that resource. The malicious site wouldn't even be able to fake the request since it’s actually the browser that handles the communication.
Passkeys can take many forms, but the most popular are FIDO2 hardware keys (such as Yubikeys), Windows Hello, and even the Microsoft Authenticator. Other password managers, such as BitWarden and LastPass have also included support for passkeys in recent years.
The primary drawback to passkeys is lack of compatibility, as it is a newer technology. Many modern authentication use cases do not support passkeys. For example, most banks (as of the writing of this post) do not offer the means to log into their site or mobile app with passkeys. However, if the fear is phishing corporate credentials associated with Microsoft Entra ID, Okta, or another identity provider, passkeys are usually fully compatible. For all other resources, you can check FIDO Alliance's Passkey Directory for a list of resources that have passkeys deployed.
Another real defense
So what else is available if passkeys aren't feasible or they're perhaps too inconvenient for your userbase? The next best thing for phishing resistance is likely certificate-based authentication (CBA). This tech has been around for many years and has been used from smart card implementations to mTLS. CBA can be implemented in all major cloud platforms, including Microsoft Entra ID, AWS, GCP, and others.
The way CBA works is a client (e.g. workstation, cell phone, etc.) receives a generated certificate pair from a Certificate Authority (CA): one public certificate and one private. The client stores their private key they used to generate the certificates in their keystore while handing over the public certificate to the resource it wishes to authenticate with. When it comes time to authenticate:
the user requests access from the server
the server presents the public certificate and requests the client certificate
the client validates the server certificate with the CA
the client then signs the nonce with its private key and gives the nonce and client certificate to the server
the server validates both with the CA
the server then grants access
CBA is a way to provide MFA functionality without much user friction. However, it's not without its drawbacks. Implementing CBA requires maintenance of a PKI infrastructure, which includes distribution of certificates and gracefully handling their revocations after their expiration. Handling this would likely require IT involvement, though much of the heavy lifting (such as certificate revocation) is handled automatically by Entra ID.
Effective detection mechanisms are sparse
While phishing prevention is best handled with phishing resistant authentication methods, how do we detect when an adversary is attempting to phish a user?
This is a difficult problem to solve, unfortunately. Some web filtering technologies could potentially inspect web pages to determine if the authentication form is mimicking common login portals, but this would require decrypting potentially sensitive network traffic, which has privacy concerns that many organizations avoid. There also seems to be a lack of help from Microsoft on this matter (even though their Defender SmartScreen claims to do this), when it's clear that their Edge browser, or even Google's Chrome, could have built-in mechanisms that can detect page forms and compare them to the URL and present warnings to the user. However, this has yet to be provided.
Lately, there have been more advancements in natural language processing (NLP) and ML-based detections in email security products, typically in the form of Integrated Cloud Email Security (ICES) offerings, such as those from Abnormal, Check Point Harmony (formerly Avanon), or Ironscales . These systems can evaluate an incoming message and generate a score based on multiple aspects, including sender reputation, SPF/DKIM/DMARC failure, message body contents and even previous communication history between the sender and recipient. However, most of these are API-based mechanisms that suffer from varying degrees of response time lag.
For more targeted attacks, when an adversary chooses to make a full duplicate of the stylings of your organization’s login portal, there is something that can be done. By including a small JavaScript honeypot, such as a Canarytoken, you can receive reports on when your site has been copied and is being hosted from a different domain. This can allow you to react quickly, such as with an automated workflow, allowing you to rapidly block the malicious domain in your firewall and/or web filter.
Key Takeaways
Phishing remains the primary way that adversaries can gain initial footholds leading to data breaches. Organizations have been led to believe that implementing TOTP-based MFA everywhere is a panacea, letting them sleep soundly. However, as has been demonstrated, it's not enough to combat modern phishing attempts. Users can and will be tricked by these false login portals, leading to session hijacks and data compromise. While security awareness training that warns users of the various phishing scenarios is still a must-have for any organization, the only way to truly provide phishing resistance is to use more advanced MFA implementations, supplemented by email security systems and other detection mechanisms.
If your organization has implemented both security awareness training and TOTP MFA controls, but are still suffering from phishing attacks, reach out to Helios Security for guidance on how to effectively eliminate this risk and safeguard your data.
