This is some text inside of a div block.
Glitch effect

To MFA or Not to MFA: How Multi-Factor Authentication Saves the SMB

|
Contributors:
Glitch effectGlitch effectGlitch effect
Glitch banner

To most people, MFA stands for “multi-factor authentication.” If you’re Samuel L. Jackson, it might mean something else, but we won’t go there.

MFA can seem like a Mostly Fruitless Annoyance at times. But today, I’d like to show you how the use or omission of MFA divides the identity attack surface cleanly in two parts, where one part presents challenges a hacker must overcome to take over an account and the other part leaves the door wide open. 

A Note Before We Begin

This blog is heavily focused on the users of the small and medium businesses (SMB) of the world. I will not go into detail about the more powerful, advanced forms of MFA because the average user in the SMB doesn't use FIDO keys, credential-based password-less authentication, certificate authentication, password managers, and the like. 

While I encourage users to use more secure forms of MFA if they can, the reality is that the average users of the SMB, if they’re even using MFA at all, are using the more basic forms. This blog is heavily rooted in my experience in defending the SMB from account takeover, so I’m here to discuss how MFA factors into that defense. 

“It’s Just Too Inconvenient!”

I only accept two reasons for why someone will not use MFA in 2024: computer literacy and access to technology. Many MFA flows require access to a smartphone, smartphone application, or at least the ability to receive a text message. Not everyone has access to this kind of technology or the computer literacy required to use this technology effectively. Accessibility and usability are always a core concern, so it’s important to consider that when looking at account takeover in the SMB.

For everyone else who omits MFA because of the inconvenience, it’s time for some real talk. 

It’s 2024. Hackers know that most people are terrible with passwords. Hackers know that most people reuse passwords across services. Hackers know that any MFA is harder to beat than no MFA. So if you or your SMB users eschew MFA due to inconvenience, like that guy from Kung Pow! Enter the Fist once said, “I implore you to reconsider.” MFA could be the thing that prevents your payroll from disappearing in a wire transaction. The rest of this blog examines exactly why MFA plays such a key role in deterring account takeover in gritty detail.

Account Takeover, Simplified

I dug up my old red team operator notes recently to find the mind map of the attack flows for identities. This is the recreation of the flow chart that I used against identities without MFA:

MFA attack flow

It is, unfortunately, extremely straightforward to attack identities that don’t use MFA. This was true in my adversary emulation days and it remains true for cybercriminals as well.

So let’s start with the assumption that if you neglect to use MFA, the barrier for hackers is extremely low. The effective attacks against identities that don't use MFA are the tried and true, aggravatingly simple set of password attacks like brute forcing, password spraying, and credential attacks. We call this class of attacks Credential Theft. Without MFA, nothing prevents a hacker from accurately guessing or discovering your identity account password and simply waltzing in the front door via standard authentication. And we at Huntress know too well that credentials are not hard to find if you know the right (read: shady) places to search.

The shady places to search for passwords
The right (read: shady) places to search

The Huntress SOC detects about 2,000 instances of suspected credential attacks every week. We identify these attacks by examining login telemetry for non-MFA identities that we observe logging in from anomalous locations and VPNs. The breakdown between anomalous locations and anomalous VPNs is about 60/40%, respectively. 

One example of credential theft included a small IT service company based in New Zealand that was observed logging into their identity from a United States IP address. The event of interest also indicated that the login was using an operating system that had never been observed before for the given identity. The event indicated that the suspect identity did not use MFA to complete this authentication. The details of this event were sufficiently suspicious and the SOC was able to stop an account takeover in progress, eject the hacker, and provide clear remediation instructions for how to prevent the attack in the future.

Incident report for credential theft
The Huntress SOC stops an account takeover in progress, ejects the hacker, and provides clear remediation instructions

Steal That Session!

On the other hand, the attacks against identities that do use MFA are more complicated (but only slightly so). MFA prevents the average class of credential attacks. Even if your password is “password123,” MFA will prevent an attacker from simply authenticating as your identity and accessing your account because they will not be able to guess the MFA code required to authenticate. Problem solved then, right?

Not really.

MFA raises the technical barrier for hackers, but the crafty among us always find a way. Session theft is the effective attack against identities that use MFA. Web services like Microsoft 365 like to stay user friendly, so instead of prompting for a username, password, and MFA code at every login, they will provide a session token to a user after authentication. The session token is usually stored in the user’s web browser and allows the user to access resources without needing to log in for every request. Instead of inputting their username, password, and MFA code, the user can simply present the token and that will satisfy the login requirements.

Adversary-in-the-Middle (AiTM)

The issue is that generally speaking, there is nothing preventing the reuse of that session token if it falls into the wrong hands. If a token can authenticate you to a service in lieu of your username, password, and MFA, then a hacker that finds or steals that token can authenticate without any of the required credentials. This is token theft. Yikes!

Token theft tactics fall into two categories: active and passive. If a hacker interacts directly with a victim to steal their token, they're engaging in active token theft. If a hacker is perusing breaches, credential dumps, and shady forum posts to procure a token, they're engaging in passive token theft. We use the shorthand of “pickpocketing” and “dumpster diving” for these categories.

Pickpocketing Tokens

Active token theft includes Adversary-in-the-Middle (AiTM) attacks, where an attacker tricks a victim into authenticating to a transparent proxy which brokers authentication to the real Microsoft 365 service. Evilginx is the most well known of these AiTM toolkits, but many Phishing-as-a-Service kits like NakedPages and Evilproxy perform similar attacks every day against the SMB.

Huntress Incident Report for AiTM attack

Dumpster Diving for Tokens

Passive token theft, on the other hand, assumes that the attacker didn’t pickpocket the token directly from the victim. Instead, passive token theft assumes that the attacker was able to find the victim’s token somewhere and replay it by injecting it directly into their browser.

But where can you find these tokens in the case of passive token theft? Again, if you know the places to look, these are not hard to find. There are entire markets in shady corners of the internet built on stolen tokens. The rise of credential stealer malware, like the Redline Stealer, has enabled the tidal wave of passive token theft attacks. Credential stealer malware, which is often distributed through SEO poisoning and malvertisement, will scrape the file system of a victim endpoint for credential information that resides in memory and on disk. The resulting credential information is then transferred to attacker-controlled infrastructure and sold for a premium.

Redline Stealer example
Redline Stealer

Interestingly enough, mitigating credential stealers is more about hardening the endpoint than hardening the identity. Credential stealers are often distributed as trojanized applications which are hosted in search engine advertisement spaces. A user may think they're downloading some popular note-taking application, but didn't realize that they actually downloaded a trojan program from a malvertisement. Once they execute the program, the credential stealer scrapes credentials from the browser and file system. Mitigating the delivery and execution of the credential stealer in this case is an effective deterrent against the resulting passive token theft attacks.

Conclusion

Account takeover continues to blight the SMB, but all is not lost! Any MFA is better than no MFA when it comes to deterring these kinds of attacks. By enforcing MFA, you're raising the technical barrier of entry for a hacker looking to score a business email compromise payday. Simple password attacks are effective against non-MFA identities, but enforcing any kind of MFA forces attackers to switch tactics to session theft. 

In reality, an attacker may simply choose to move onto the next target that does not use MFA to continue their attack. Or they may invest time into executing a session theft attack. But regardless, the point here is that attackers should have to fight for their access. MFA is one of the most effective ways to raise the technical barrier to entry and make it harder for attackers to succeed. 

Share

Sign Up for Blog Updates

Subscribe today and you’ll be the first to know when new content hits the blog.

By submitting this form, you accept our Privacy Policy
Huntress at work
Cybersecurity Education
Cybersecurity Education