Retool, the company behind the popular development platform for building in-house enterprise software, suffered a breach that allowed attackers to access and take control of the accounts of 27 cloud customers, all from the crypto industry.
It all started with a text message
The attack began with spear phishing text messages sent to a number of Retool employees. According to the company, only one signed up to the project.
The phishing text message. (Source: Retool)
The goal was to have targets log into a fake Retool identity portal, after which they would receive a phone call from the attacker.
“The caller pretended to be one of the IT team members and falsified the real voice of our employee. The voice knew the office layout, the colleagues and the company’s internal processes. Throughout the conversation, the employee became increasingly suspicious, but unfortunately provided the attacker with an additional multi-factor authentication (MFA) code,” Snir Kodesh, head of engineering at Retool.
“The additional OTP token shared during the call was critical because it allowed the attacker to add their own personal device to the employee’s Okta account, allowing them to create their own Okta MFA from that that moment. This allowed them to have an active GSuite session (i.e. Google Workspace) on that device.
And because the employee’s MFA codes were synced to their Google account, the attacker now had access to all MFA tokens held in that account.
“Thanks to these codes (and the Okta session), the attacker accessed our VPN and, above all, our internal administration systems. This allowed them to launch an account takeover attack on a specific set of customers (all in the crypto industry),” Kodesh noted, and added that the attacker also snooped through some of the Retool apps – but did not did not specify which ones.
“We have an internal Retool instance used to provide customer support; this is how the account buyouts were executed. Authentication for this instance is done via VPN, SSO, and final MFA. A valid GSuite session alone would have been insufficient.
Whose fault is it ?
“Social engineering can affect anyone,” Kodesh noted, and “even with perfect training and knowledge of these attacks, mistakes will happen.” He also placed blame for the hack on Google.
The company recently released the Google Authenticator sync feature that syncs MFA codes with the cloud and makes it easy to activate the feature.
“Unfortunately, Google uses dark templates to convince you to sync your MFA codes to the cloud, and our employee had actually enabled this “feature.” If you want to disable it, there is no clear way to “disable cloud sync”, there is simply an option to “unlink Google account”. In our corporate Google account, there is also no way for an administrator to centrally disable the Google Authenticator sync “feature,” he said. explain.
“Thanks to this update from Google, what was previously multi-factor authentication had silently (for administrators) become single-factor authentication, because controlling the Okta account led to controlling the Google account, which led to the control of all stored OTPs. in Google Authenticator.
If the company had used a FIDO2-compliant hardware security key instead of one-time passwords provided through an authenticator app, this particular social engineering attack would have failed – as did an attack similar against Cloudflare employees. one year ago.
Of course, Google cannot be entirely blamed for this breach – Retool should have regularly reviewed the protections put in place and assessed whether they are still adequate. After all, attackers have been finding ways to bypass multi-factor authentication for some time now, and the threat landscape is evolving rapidly.
Attackers are constantly improving old techniques and implementing new ones (case in point: using deep generative methods to simulate the voice of an IT employee).
The investigation is ongoing
Retool is working with law enforcement and a third-party forensics company to fully investigate the breach.
So far, they’ve found that 27 cloud customers have been affected (and they’ve notified them all), but on-premises Retool customers remain secure.
“Retool on-prem operates in a zero trust environment and does not trust the Retool cloud. It is completely self-contained and does not load anything from the cloud environment. This meant that even if an attacker had access to the Retool cloud, there was nothing they could do to affect on-premises clients,” Kodesh noted.
Fortress customers, on the other hand, reportedly lost nearly $15 million.