TotalCloud Insights: When Multi-Factor Authentication Turns Into Single-Factor Authentication

Introduction

Multi-factor authentication (MFA) failures have fuelled a 500% surge in ransomware losses, as noted in an article published by “The Hacker News”—from an average ransom payment of $400,000 in 2023 to $2 million in 2024. And attacks exploiting an MFA failure are getting increasingly advanced. Case in point: In Q3 2023, Retool, a development platform company, faced a significant cybersecurity incident when attackers accessed the accounts of 27 cloud customers despite robust MFA. This breach highlights the evolving sophistication of cyber threats and the need for continuous improvement in security measures. In this article, we will give a short primer on why it is important to unpack MFA failures like this one, explore the details of the Retool attack, and outline the critical lessons learned for enhancing cloud security.

Why Is Understanding MFA Failures Important?

Multi-factor authentication (MFA) is a security measure that requires users to provide two or more authentication factors to verify their identity. These factors can include a password, an OTP (One-Time Password) on a mobile device, or a biometric scan. MFA is generally considered more secure than single-factor authentication (SFA), which only requires a password.

Despite its robustness, MFA is not foolproof. There have been several cases where MFA has failed to prevent attackers from accessing user accounts. A notable example is the recent Retool breach, where 27 cloud customers’ accounts were compromised despite MFA being enabled. MFA can fail for several reasons, including phishing attacks, social engineering, man-in-the-middle attacks, and device compromise. Attackers often trick users into revealing their MFA credentials. For instance, an attacker might send a phishing email that appears to be from a legitimate company asking the user to enter their MFA code—exactly what happened in the Retool case.

Understanding the Retool Attack

The Retool attack is a prime example of how sophisticated phishing tactics can bypass even robust security measures like multi-factor authentication (MFA). By exploiting vulnerabilities in human behavior and technological features, attackers gained unauthorized access to critical systems and data. Here’s a detailed breakdown of how the Retool attack unfolded. This will allow us to understand the steps the attackers took and how such incidents can be prevented in the future.

Spear Phishing Attack Breakdown

• Initial Attack: Everything started with a spear phishing attack. The attacker, posing as a colleague, sent a crafted message concerning a payroll system issue that required immediate attention. The timing coincided with a recently announced migration of logins to Okta.
• Phishing Link: The unsuspecting victim was directed to a link (https://retool.okta.com.[oauthv2.app]/authorize-client/xxx) that looked legitimate but instead masked malicious intent.
• Fake Portal Login: The attacker called the employee after logging in to the fake portal, which included an MFA form. Using the deepfake voice of an IT team member, the attacker requested the victim to provide the MFA code.
• MFA Code Compromise: After obtaining the MFA code, the attacker added his device to the victim’s Okta account and enabled an active GSuite session. This allowed the attacker to exploit a feature in Google Authenticator – synchronizing MFA codes to the cloud.
• Cloud Synchronization Exploit: The unsuspecting victim had unwittingly synchronized their MFA codes to the cloud, a default setting when installing Google Authenticator. This provided the attacker with access to all the OTPs stored in Google Authenticator, turning what was perceived as multi-factor authentication into a single-factor authentication vulnerability.

The Consequences of an Identity and Access Management App Compromise

Let us consider the above case: once access to Okta, the identity and access management app, was gained, the attacker could then log in to multiple apps assigned to the user in the Okta Dashboard. In most corporate environments, these apps typically include collaborative productivity tools like GSuite and Office 365, Human Capital Management (HCM) apps like Workday, and Cloud Service Providers like AWS (Amazon Web Services), Microsoft Azure, or Google Cloud Platform (GCP).

Access to Collaborative Productivity Apps

When an attacker gains access to collaborative productivity apps like GSuite, Office 365, etc.,  they can access various organizational documents, slides, and sheets. Additionally, the attacker can access email apps and use the information for spear phishing other employees within the organization. 

Access to Human Capital Management (HCM) Systems

Accessing an HCM tool like Workday or a similar platform allows attackers to view, steal, or manipulate sensitive employee information, including personal details, social security numbers, addresses, and bank account information. This data can be exploited for identity theft, financial fraud, or other malicious activities.

Access to Cloud Service Providers (CSPs)

If an attacker gains access to an Okta account linked to CSPs like AWS, Azure, or GCP, the consequences can be severe. The attacker can access cloud resources, including servers, databases, storage, and other assets hosted on the cloud. This can lead to data theft, data manipulation, or even the complete compromise of the cloud infrastructure.

Critical Security Lessons from How This Attack Took Advantage of Google Authenticator Cloud Sync

When you install Google Authenticator from the app store and follow the default setup instructions, your MFA codes are automatically saved to the cloud. There is no straightforward way to “disable syncing to the cloud” if you want to turn off this setting where MFA codes are automatically saved to the cloud. The only option is to “unlink Google account.” Even within corporate Google accounts, administrators cannot centrally disable Google Authenticator’s sync feature.

Having access to a Google account provides immediate access to all MFA tokens held within a cloud account. This creates a significant security vulnerability as it allows an attacker to breach any internal system or account linked to those tokens.

The fact that Google Authenticator syncs to the cloud introduces a novel attack vector. This implies that a multi-factor authentication can silently (to administrators) degrade into single-factor authentication because control of the Okta account leads to possession of the Google account, which, in turn, provides access to all OTPs stored in Google Authenticator.

How Qualys TotalCloud can help mitigate the MFA failure

Qualys TotalCloud provides various insights to understand which access entitlements exist across cloud environments and then identify and mitigate risks resulting from entitlements that grant a higher level of access than they should.

Conclusion

In conclusion, the Retool breach is a stark reminder that even the most robust multi-factor authentication (MFA) systems can fall victim to evolving cyber threats. This incident sheds light on critical vulnerabilities that can be exploited when users unknowingly sync their MFA codes to the cloud, effectively transforming a multi-factor authentication system into a single-factor authentication vulnerability.

The spear phishing attack that initiated this breach demonstrates the cunning tactics employed by cybercriminals, leveraging social engineering and deepfake technology to trick an unsuspecting employee into revealing their MFA code. 

Given these challenges, it is crucial for organizations to remain vigilant and continuously educate their users about the importance of MFA and cybersecurity best practices. As the threat landscape evolves, so too must our security measures. Retool’s experience is a valuable lesson in the ongoing effort to bolster cloud security and protect sensitive data from determined adversaries.

Contributors

• Rahul Pareek, Security QA Engineer, Cloud, Qualys