Case Library / Phishing / Retool breach (2023): a fake IT text, a phone call and synced MFA codes

Retool breach (2023): a fake IT text, a phone call and synced MFA codes

A fake IT text and phone call got a Retool employee's MFA codes in 2023. Google Authenticator sync did the rest: 27 crypto accounts hijacked. What happened.

Share:

Social Engineering Examples·8 sources

In August 2023, attackers sent Retool employees a text posing as IT, about a payroll sync for open enrolment, with a link to a fake Okta login. One employee entered a password and a one-time code. Then the attacker phoned them, posing as IT again, and got a second code. That let the attacker add their own device, and because the employee's Google Authenticator synced to the cloud, one account opened many others. The attacker took over 27 crypto customers' accounts. Status: Documented incident; deepfake claim unverified.

Key takeaways

  • The text arrived during a real Okta migration, so the request felt routine.
  • The second code, read out over the phone, was the one that mattered. It let the attacker register their own device.
  • Google Authenticator's cloud sync turned one stolen Google account into codes for Okta, the VPN and internal tools.
  • Retool says the caller deepfaked a real employee's voice. It offered no evidence, and Ars Technica called the claim "completely unverified".

The text and the call

Several employees got a text from "IT" saying their payroll system was out of sync and needed fixing for open enrolment. The link looked like Retool's own login: retool.okta.com followed by more text. But the real domain was oauthv2.app. Everything before it was just words the attacker chose.

Nearly everyone ignored it. One person logged in on the fake page and entered a password and a one-time code. The attacker then called that person, posing as IT. Retool says the caller knew the office floor plan, colleagues and internal processes. The employee grew more suspicious as the call went on, but still gave one more code.

Tip: read a link from right to left. The real domain is the last part before the first single slash. Anything to its left can say whatever the attacker wants.

How one code became 27 accounts

Step What happened
Text Fake IT message with a lookalike Okta link (smishing)
First code Entered on the fake login page
Call Fake IT on the phone gets a second code (vishing)
Own device The second code let the attacker add their device to the employee's Okta account
Cloud sync Access to the employee's Google account exposed every code stored in Google Authenticator
Spread VPN, then an internal customer-support tool
Takeover Changed emails and reset passwords on 27 cloud customer accounts, all crypto firms

Retool told the 27 customers on 29 August, closed all internal sessions and restored the hijacked accounts. Customers running Retool on their own servers weren't affected.

The deepfake claim

Retool's write-up says the caller "deepfaked our employee's actual voice". That's the only evidence. Retool released no audio and no forensic finding, and its head of engineering declined to explain further when Ars Technica asked. Ars called it "a separate and completely unverified claim" and suggested it might distract from Retool's own role. The insider knowledge, which nobody disputes, is enough on its own to explain a convincing call.

The money

Retool never said money was stolen or named its customers. The loss comes from the customer side. Fortress Trust, a Nevada trust company, said four of its customers were hit through a breached cloud vendor. It first said there was "no loss of funds". Five days later its chief executive told Fortune the loss was $12 million to $15 million in crypto, mostly Bitcoin. CoinDesk identified the vendor as Retool. Neither company has confirmed the link on the record.

Fortress said it repaid most affected clients from its own funds within 48 hours, and Ripple covered one larger client.

What would have stopped it

  • Phishing-resistant MFA, like hardware keys, which can't be read out over the phone.
  • Turn off cloud sync for authenticator apps on work accounts, or use a separate app.
  • IT never asks for codes. Make that a rule everyone knows.
  • Verify callers by hanging up and calling IT back on a known number.
  • Alert on new devices added to identity accounts.

See also 0ktapus, a similar Okta-themed smishing campaign, and account takeover.

Common questions

How was Retool hacked?

A fake IT text led one employee to a lookalike Okta page, and a follow-up call got a second code. That let the attacker add their own device and reach internal tools.

Did the Retool attackers use a deepfake?

Retool says the caller faked an employee's voice, but it gave no evidence, and Ars Technica called the claim completely unverified.

Why did Google Authenticator make it worse?

Its cloud sync stored the employee's one-time code secrets in their Google account. Once the attacker had that account, they had the codes too.

How much was lost in the Retool breach?

Retool gave no figure. Fortress Trust, reported to be a Retool customer, said it lost $12 million to $15 million in crypto.

Sources
  • When MFA isn't actually MFA. Retool, authored by its head of engineering, September 13, 2023 (primary). First-party incident disclosure; source of the SMS text verbatim, the phishing URL, the deepfaked-voice claim, the Okta and Google Authenticator cloud-sync chain, the 27 crypto customer takeovers, and the remediation. Interested party on the question of fault.
  • How Google Authenticator made one company's network breach much, much worse. Ars Technica, September 15, 2023 (secondary). Technical analysis of the cloud-sync amplification; states that Retool's head of engineering declined to clarify what he meant by OTP token; calls the deepfake claim "a separate and completely unverified claim"; argues the root weakness was Retool's reliance on phishable one-time codes; carries Google's response in full.
  • Phishing Attack on Cloud Provider With Fortune 500 Clients Led to $15M Crypto Theft From Fortress Trust. CoinDesk, September 13, 2023 (secondary). Identified the vendor Fortress had blamed but not named as Retool, citing people familiar with the matter; reports the theft as close to $15M; carries the Ripple spokesperson's statement that Fortress covered most affected customers and Ripple covered the rest; notes Nevada's Financial Institutions Division was notified on September 1.
  • Fortress CEO says hackers stole up to $15 million, mostly in Bitcoin, prior to Ripple acquisition. Fortune, September 12, 2023 (secondary). Origin of the $12M to $15M range, stated on the record by Fortress's chief executive; four affected customers out of about 225,000 accounts; mostly Bitcoin with small amounts of USDC and USDT.
  • Fortress CEO Clears the Air on Security Breach and Stolen Funds. Decrypt, September 12, 2023 (secondary). Fortress's chief executive on the reimbursement mechanics: most affected clients made whole from Fortress's own balance sheet within 48 hours, Ripple covering one larger client's balance by September 5; also the initial "no loss of funds" statement and the vendor-blame framing.
  • Developer platform Retool breached in vishing attack. TechTarget, September 14, 2023 (secondary). Corroborates the timeline (August 27 attack, August 29 notification), the smishing plus vishing method, the Okta involvement, and Fortress Trust's own statement that four of its customers were affected; carries Google's statement.
  • Google Feature Blamed for Retool Breach That Led to Cryptocurrency Firm Hacks. SecurityWeek, September 15, 2023 (secondary). Corroborates the account-takeover mechanics and the $15M Fortress Trust figure via CoinDesk; notes similarities to the 0ktapus / Scattered Spider / UNC3944 playbook without attributing the attack.
  • Ripple Cancels Plan to Buy Fortress Trust. CoinDesk, September 28, 2023 (secondary). Confirms Ripple's September 28, 2023 decision not to proceed with the outright acquisition, while remaining an investor.
Cite this case

Social Engineering Examples. “Retool breach (2023): a fake IT text, a phone call and synced MFA codes”. Accessed 3 November 2026. https://socialengineeringexamples.com/retool-smishing-vishing-deepfake-2023

Attack Chain & Defense
1Reconnaissance
What happened

the attackers arrived knowing Retool's office floor plan, coworker names, internal processes and the freshly announced Okta login migration. Retool did not say how that detail was gathered, and no source establishes the method; professional-networking profiles, prior breach data and public company announcements are the usual candidates. Treat the sourcing as unknown and the effect as certain.

The control that would have stopped it

Employee-facing exposure (roles, org charts, announcements of internal changes) is very hard to eliminate at enterprise scale. The realistic control assumes the attacker already has it and hardens the process it gets used against, rather than trying to hide it.

2Infrastructure setup
What happened

the attackers stood up a look-alike Okta login page, complete with an MFA form, on a domain they controlled. Retool published the URL: retool.okta.com.[oauthv2.app]/authorize-client/xxx. The only part that decides where the link goes is oauthv2.app; retool.okta.com is hostname text the attacker chose so the URL would read as Retool's real portal at a glance.

The control that would have stopped it

Domain-monitoring and typosquat takedown services catch some look-alike domains, and staff can be taught to read a URL from the right, since the registrable domain is the only part that decides destination. Neither is reliable enough to stand alone, so the real control sits at Stage 4.

3Smishing (initial contact)
What happened

a text message impersonating a member of Retool's IT team went to several employees, saying their payroll system was out of sync and that it needed to be synced for open enrollment, which affects healthcare coverage. The timing coincided with the real Okta migration, so the request read as routine.

The control that would have stopped it

Mobile threat defense and carrier-level filtering catch some lures, but the durable control is training that treats any unsolicited SMS about account or benefits problems with an embedded login link as suspect, to be verified through a known internal channel rather than the number that texted.

4Credential and first-OTP harvesting
What happened

almost all employees ignored the text. One logged into the fake portal and entered a password plus a one-time MFA code.

The control that would have stopped it

Phishing-resistant, hardware-backed MFA (FIDO2 security keys or passkeys) removes the one-time code entirely, so there is nothing on the fake portal for the employee to hand over. Retool acknowledged that FIDO2 provides resilience to this attack, and did not say why it was not in use.

5Vishing call and second-OTP extraction
What happened

the attacker phoned the same employee, claiming to be a member of the IT team, and demonstrated familiarity with the floor plan, coworkers and internal processes. Retool says the caller also deepfaked a real employee's voice, a claim no one has verified. The employee grew more and more suspicious during the call and still provided one additional MFA code.

The control that would have stopped it

A strict no-OTP-by-phone policy plus callback verification through a known internal number removes the payoff from a convincing call, whatever the caller sounds like. Voice is not authentication even when it is genuinely the right person's voice, which is why the unresolved deepfake question does not change the control.

6Durable MFA takeover
What happened

that second one-time code let the attacker add their own device to the employee's Okta account, so they could generate valid Okta MFA from then on, and it gave them an active Google Workspace session on the attacker's device.

The control that would have stopped it

Alerting on new-device MFA enrollment and gating it behind out-of-band approval would have stopped the attacker's device registration from silently granting durable Okta access.

7Privilege amplification via OTP cloud sync
What happened

the employee had enabled Google Authenticator's cloud-sync feature, so control of the Google account exposed the OTP seeds stored there. Retool used OTPs for Google, Okta, its VPN and its own internal Retool instances, and argues that this is what turned its multi-factor authentication into single-factor authentication. The attacker reached the VPN and an internal Retool instance used for customer support.

The control that would have stopped it

Do not let OTP seeds sync to personal cloud accounts. At the time Google offered enterprises no central switch to disable Google Authenticator sync, so the practical answer was to move off shared-secret OTPs to FIDO2 or passkeys, or to mandate an authenticator whose sync is off by default and end-to-end encrypted.

8Lateral movement to customer accounts
What happened

using that internal support instance, the attacker ran account-takeover actions, changing user emails and resetting passwords, against 27 of Retool's cloud customers, all cryptocurrency firms, then looked around some of the Retool apps.

The control that would have stopped it

Segmenting and monitoring internal admin and customer-support tooling, with least-privilege scoping and anomaly detection on bulk email or password changes, limits how far one compromised session reaches into customer accounts.

9Objective completion
What happened

Retool's own account stops at account takeover and never states that funds were stolen. The theft is documented on the customer side only: Fortress Trust said four of its customers were affected, and its chief executive put the loss at $12M to $15M in crypto. Retool revoked all internal sessions, locked down the affected accounts, restored them to their original state and notified the 27 customers on August 29.

The control that would have stopped it

Fast session revocation and account restoration limited Retool's own blast radius. On the customer side, withdrawal holds, address allowlisting and out-of-band confirmation for high-value crypto transactions are the last line once account takeover has already happened. Retool noted that customers who had built their apps with their own threat model in mind repelled the attack even after their accounts were taken over.

Quick Facts
Victim
Retool, Inc. (San Francisco-based developer and internal-tools platform); 27 of its cloud customers, all cryptocurrency firms, none of which Retool has ever named.
The only publicly identified downstream victim is Fortress Trust, a Nevada chartered trust company, which said four of its own customers were affected by a breach at an unnamed third-party vendor; CoinDesk identified that vendor as Retool.
Company
Retool, Inc.
Location
San Francisco, California, USA (Retool); downstream victim Fortress Trust, Nevada, USA
Date
2023-08
Impact
Roughly $15M in cryptocurrency taken from four customers of Fortress Trust.
BasisestimateThe case states the basis: an estimate, not a measured transfer, and not Retool's loss
This is not Retool's loss and Retool has never stated a dollar figure or confirmed Fortress was among the 27. Basis: estimate, not a measured transfer. Fortress's chief executive told Fortune (12 Sep 2023) the firm lost $12M to $15M, mostly Bitcoin with small amounts of USDC and USDT; CoinDesk (13 Sep 2023) reported the total as close to $15M. Fortress had said on 7 Sep 2023 that there was no loss of funds, then its chief executive revised that publicly five days later. Recovery: Fortress made most affected clients whole from its own balance sheet within 48 hours and Ripple covered one larger client's balance by 5 Sep 2023 (Fortress's chief executive to Decrypt; corroborated by a Ripple spokesperson to CoinDesk). Retool reverted all 27 account takeovers. Ripple, already a minority investor, signed a letter of intent on 8 Sep 2023 and canceled the outright acquisition on 28 Sep 2023 while remaining an investor.
Status
Documented incident
Case Type
Real-World Incident
Sector
Cryptocurrency & Digital Assets, Financial Services & Insurance, Technology & Software
Threat Actor
unknown
Explore more

Related Cases

Browse by what this case has in common with others in the library.