How Multifactor Authentication Stops Hackers: 3 Mini Case Studies

Woman logging into computer with multifactor authentication

Here are the stories of three dangerous—and common—information security incidents. The common thread? One relatively simple security control could have stopped each one. 

  1. A bank discovers that someone has emptied a customer’s checking account without their knowledge. Upon investigation, the bank discovers that the customer’s username and password, which the customer reused for numerous other websites, were stolen from a hacked WordPress site for the customer’s book club. Then hackers included the customer’s information in a credential stuffing attack. (In credential stuffing, hackers throw thousands of stolen usernames/passwords at many websites, hoping that some will unlock accounts.)
  2. An organization discovers its confidential intellectual property (IP) available for sale on the internet. An investigation reveals a phishing attack as the culprit. Hackers acquired an employee’s VPN account credentials via a fraudulent e-mail, then downloaded the data from an internal server to an IP address overseas.
  3. On the Friday before a long weekend, a company gets hit with a ransomware attack. Its internal production server with customers’ personally identifiable information (PII) has been encrypted, and attackers are demanding a payment to unlock it. After several sleepless nights of incident response and investigation, company IT leaders discover that a hacker initially compromised a poorly patched Windows server in the DMZ and then installed keystroke logging malware to harvest credentials from an administrator logging in to the server. The hacker then reused these administrator credentials to establish a Remote Desktop Protocol session to the internal production server and install ransomware.

Each of these stories highlights everyday dangers rooted in the fact that the traditional approach of authenticating a user’s identity and system access with a username/password has mostly broken down. It has fallen victim to an explosion in the huge numbers of account usernames and passwords that the average individual must keep track of to function in modern life. (My personal password vault currently has 492 unique accounts). That leads to most people using easy-to-remember passwords or reusing a handful of passwords across many accounts. One report says that 73% of all online accounts use duplicated passwords. 

In this environment, businesses and organizations must provide their users with tools to simplify good security practices. The answer is not requiring ever-longer and more complex passwords, but to implement additional or different factors to authenticate users to systems beyond just passwords and PINs. 

Each of the attacks described above would’ve been stopped in its tracks by multifactor authentication (MFA). This tool (sometimes called two-factor authentication or 2FA) provides a powerful defense against most attacks—especially those involving access or passwords. In fact, Microsoft, which is spending more than $1 billion on security annually, is on record as saying that MFA can block more than 99.9 percent of account compromise attacks. 

In a recent HBS webinar, cybersecurity expert Terry McGraw of PC Matic said, “The one thing I would do today if I hadn’t already done it is implement MFA. I need to make sure everyone touching my environment is authenticated from the system they’re working on.” 

Three Key Factors of MFA 

A secure system incorporates at least two of the following factors when authenticating users: 

  • Something you know - A password or passphrase. 
  • Something you have - Generally based on some form of encryption to validate authenticity such as a USB key, common access card (the CAC used by the Defense Department), digital certificate, phone app that generates or receives one-time passwords (OTPs), or hardware/software token. 
  • Something you are - Retina (retina scan), fingerprint (fingerprint reader), face (facial recognition). 

Each factor has pros and cons, but, in general, using any of these in addition to passwords improves the security of the system or application in question and provides an additional layer of defense desperately needed in today’s environment. 

At particular risk are systems, applications, and users that are exposed to the Internet, as well as privileged users and users of sensitive systems/applications. These types of systems should be the priority for MFA/2FA implementations because they are at the highest risk of attack. 

How MFA Stopped the Attacks 

Returning to our initial three examples, let’s explore how some form of MFA could have prevented or lowered the impact of these incidents. 

  1. A bank account hacked through credential stuffing - Even if the hacker stole the username/password, they wouldn’t get very far. The web banking system could be configured to require the user to enter a one-time password or code from an app before providing access to the online account. In this model, the user would have been notified of the unauthorized access attempt when they received an unexpected code. The attacker could get into the account only if they also compromised the user’s phone so they could receive the code.
  2. IP stolen through a VPN - Even if the phishing attack successfully harvested the username and password from the employee working at home, the company could stop the hacker by requiring the entry of a code from a hardware token before allowing access to the VPN. In this setup, the user gets the code from a device such as a fob specifically set up to deliver unique codes for logins.
  3. A ransomware attack carried out via password logging - Even if an attacker successfully compromised the DMZ server and captured the administrator’s credentials, MFA or 2FA can stop the attack. Without the unique code sent to the administrator, the attacker would not be able to successfully log into the production server in order to install malware.

MFA Best Practices 

When considering your MFA setup, remember this key concept: Authentication factors should be separated from the system the user is authenticating from. For instance, a user should not receive an e-mail with a one-time password (OTP) as an MFA factor for accessing a VPN through the same e-mail account they use to access the VPN. A hacker who compromises that e-mail account has access to both the MFA factor (the e-mail delivering the OTP) and the user’s password. This bypasses the additional level of defense that the MFA implementation was intended to provide. 

Moreover, the added security provided by MFA is only as good as the secrecy of the additional factor being used. For example, consider the rise in cell phone SIM swap attacks, where a malicious hacker uses a victim’s personal information to take control of a victim’s mobile phone number. A successful SIM swap allows an attacker to masquerade as their victim for any account tied to the victim’s phone number. This also subverts the security of any systems sending SMS OTPs to the victim’s phone as an additional authentication factor. 

The increase in SIM swap attacks in recent years highlights the risk of using SMS-based OTPs as an additional authentication factor. While SMS OTPs are probably still sufficient for some individuals and organizations, those with a low risk tolerance will probably want to invest in a more robust MFA implementation to secure systems or data (for a deeper drive into MFA guidelines from NIST, see this article). 

Obviously, no security control is a silver bullet. But if you are looking to make a big impact on risk reduction for your organization, MFA is a great place to consider investing. To talk with one of our experts on how you can implement MFA in your organization, contact us today. 

author avatar
Carly Westpfahl