Digital transformation, widespread remote work due to the COVID-19 pandemic and ever-increasing reliance on cloud services and infrastructure have all contributed to new enterprise access challenges. And for many organizations, 2020 was the year that multi-factor authentication (MFA) became a “must-have” security control to help protect against credential theft, while segmenting critical assets to make it harder for attackers to reach their goals.
The case for MFA is strong. Last year, Microsoft engineers revealed that 99.9% of the compromised accounts they track don’t use MFA. Meanwhile, Google found that even a basic two-factor authentication method — such as a text message that generates a one-time-password through cellular networks (SS7) — can stop 100% of all automated attacks, 96% of bulk phishing attacks and three-quarters of targeted attacks.
MFA should be considered a foundational security control and part of a layered and holistic Zero Trust strategy. When designed or implemented incorrectly, MFA infrastructure can be compromised and used in the attack chain. And as attackers continue to innovate, they’re finding new, creative ways to target MFA and circumvent these critical security controls. Take, for example, the Golden SAML MFA bypass technique utilized by the SolarWinds attackers to achieve persistent anytime, anywhere access to victim networks. As part of this major breach, an MFA tool suffered credential compromise when attackers stole a secret key stored within the tool itself. As Golden SAML and other novel attack techniques take hold, other threat actors will likely look for ways to steal unprotected credentials stored within MFA tools to gain unauthorized access.
CyberArk Red Team services are designed to provide a safe way for security operations teams to test and measure their ability to defend against attacks on their on-premises and cloud environments. Since early 2020, we’ve received a spike in MFA bypass adversarial simulation requests from customer organizations around the world. Throughout these engagements, our post-breach remediation work and collaborative research with CyberArk Labs, we’ve identified four main attack vectors used by threat actors to circumvent MFA controls: architectural and design flaws, insecure channels, side channel attacks and insufficient attack surface coverage.
Here’s a look at some real-world attacks against MFA controls:
MFA Attack #1: Manipulate Architectural and Design Flaws
Many organizations deploy single sign-on (SSO) with MFA to mitigate the risk associated with credential theft.
In a recent engagement, a large global organization used a third-party MFA provider to secure its VPN access. Once connected to the VPN, remote users would use SSO to access various cloud services. However, during our testing, we found that when users logged in from a trusted IP within the VPN range, they were only prompted for their domain credential before obtaining access to any cloud service.
This revealed a fundamental architectural flaw: MFA was only applied for infrastructure-based access but not for individual user identities accessing critical assets. This rendered the MFA controls useless, leaving the organization susceptible to a single-factor attack. By simply compromising a user’s workstation and obtaining access to a soft token application installed on that machine, we could log in to the VPN, switch out users with ease using any other single user password and access everything from the CEO’s email to all-powerful cloud consoles.
Figure 1: By compromising “Bob’s” workstation and gaining access to his soft token application (installed on his machine), we could use Bob’s token to access the VPN on his behalf. Once logged in, we would use “Alice’s” password to switch out users.
MFA Attack #2: Exploit Insecure Token Onboarding Processes
In this particular Red Team engagement, our goal was to pivot into an organization’s sensitive industrial networks protected by MFA tokens. We gained initial access to the IT network and started reviewing user emails, quickly noticing something strange about the initial onboarding process. New users would receive an email containing a URL that they needed to click in order to pair their phone’s MFA soft token with their user identity in the company’s MFA server.
Unfortunately, that link also contained the cryptographic seed of the user’s MFA token — or in other words, the primary cryptographic key materials used to generate the token. The good news was that the seed was protected by a PIN code.
With emails in hand, we had access to these cryptographic seeds — and only needed the PIN code and timestamp to create duplicate MFA tokens and generate our OTP codes on behalf of the user. We soon learned that every single seed was protected by a simple four-digit code, which could be cracked within seconds. This gave us the ability to brute-force the seed to any MFA token in the organization and replicate any user’s MFA token at will — giving us full access to the industrial network.
Figure 2: By brute-forcing the cryptographic seed to any MFA token in the organization and replicating any user’s MFA token as needed, we gained access to the industrial network.
MFA Attack #3: Attack Browser Cookies Post-Authentication
Post-MFA authentication attacks targeting browser cookies are becoming some of our team’s favorite adversary simulation attack methods, considering they can be executed remotely after certain conditions are met.
For this engagement, our main objective was to abuse or steal client-side session cookies, which are set post-authentication on the end user’s browser. For example, once you log in to Gmail using your credentials and MFA token, you’re issued session cookies that are stored encrypted in your browser. These cookies are sent with every request to Gmail subdomains so you don’t have to keep logging back into Gmail every time you close your browser.
On Windows systems, these cookies are encrypted using a cryptographic interface called Data Protection Application Programming Interface — DPAPI for short. Essentially, DPAPI allows a user to make a single API call to encrypt or decrypt a blob of data without requiring local admin rights. In any domain-joined environment, there exists a domain-wide backup key that can decrypt any DPAPI-encrypted blob in the entire domain. What’s more, once this backup key is created, it’s never rotated.
Since DPAPI is designed for application in user context, it’s easy to decrypt users’ browser cookies and passwords using their own credentials by calling one simple Windows API. And by gaining access to the domain keys, we could scale the attack across every user and machine in the domain from afar.
Figure 3: Using the Data Protection Application Programming Interface (DPAPI), we could decrypt users’ browser cookies and passwords using their own credentials.
MFA Attack #4: Target Critical Assets Through Secondary Channels
When resources can be accessed through multiple channels, organizations commonly miss securing secondary channels. We see this all the time during Red Team engagements.
In this particular case, an organization had set up MFA for an admin to access certain critical servers via Remote Desktop Protocol (RDP). When a privileged user logged in using RDP to a server, Windows OS would call the MFA provider installed as a separate module. The user would receive a push notification on their phone and would need to verify the login attempt. Once they approved the request, the user would be granted interactive access to the server through RDP.
This meant that if an attacker were to obtain an admin username and password for the server, they would still be prevented from accessing the server over RDP, which is great news. But RDP is only one inbound interface on the server. What about other channels? In Active Directory (AD) environments, remote management ports are enabled by default; other protocols like Server Message Block (SMB) and Remote Procedure Call (RPC) can be accessed with tools such as PsExec, Powershell and other direct COM objects. These protocols are exempt from second factor, as most MFA modules do not cover non-interactive communication. The attacker would be able to log in and gain access to the server using only a username and password.
Adopting an Attacker’s PoV to Strengthen MFA Implementations
CyberArk Red Team uses these discoveries to help our customers understand evolving threats from the attacker’s perspective — enabling them to proactively defend their organizations, protect what matters most and stay one step ahead. By working side by side with our team of expert researchers, organizations can also define critical baselines from which future security improvements can be measured.
Without a doubt, MFA is a critical security mechanism for our global mobile world. As Red Teamers, it makes our lives much more difficult. But MFA needs to be considered in the context of multi-layered Identity Security controls, including strong privileged access controls like session isolation and credential management. And just like any aspect of security, design matters. Implementation matters. And most important, operational security matters. You are only as secure as your weakest link.
I’m presenting this research today at IMPACT LIVE 2021 in the “Learn from Labs and Red Team” track. Register now to take a deeper dive into the “Good, Bad and Ugly of MFA Bypass Techniques.” You’ll also find sessions on emerging cyber threats, gain insight into the attacker’s mindset and experience and shape the future of Identity Security
