A fake human-verification page tricked a Fomo user into installing a malicious browser bookmark designed to steal login tokens and wallet-related data, according to a SlowMist investigation published on October 8, 2026, at 19:00 UTC+8.
The user reported losing approximately $48,000 after following a project website link displayed on Fomo’s MOONLET token-details page. SlowMist separately identified 45,106.85 USDC withdrawn in three transactions based on information supplied by the victim. These are distinct figures in the report, not interchangeable measures of the loss.
The user said they had signed in to Fomo through Google, had not enabled two-factor authentication, and had neither connected a wallet nor approved an on-chain authorization or entered a seed phrase or private key during the incident.
SlowMist’s analysis explains how the bookmark could collect credentials from an authenticated Fomo page. It does not establish the precise method used to transfer the assets afterward.
How the verification trap worked
According to screenshots and the user’s account, the external link appeared beside the MOONLET token name and in the project-information section on Fomo. It led to voltage[.]family.
The phishing site’s /app page displayed nine icons and asked visitors to find a four-legged animal, drag it into their browser’s bookmarks bar, and click the resulting bookmark three times. The bookmark was named “Triple click to verify.”
Instead of a normal web address, it contained a javascript: URL—a bookmarklet. Clicking a bookmarklet runs its JavaScript in the context of the currently open page. In this case, the objective was to persuade the victim to execute it on an already authenticated Fomo page.
The animal-selection task was a pretext. SlowMist found that fomo-track.js assigned the same malicious code to every selectable icon, regardless of which animal the user chose. It repeatedly replaced the bookmark links during page changes, timer events, mouse presses and dragging.
A subsequent /app/live page imitated a trading terminal. Its market data was labeled as simulated, and its connect-wallet button only displayed a message. SlowMist assessed these screens as supporting the phishing site’s appearance of legitimacy.
What the bookmark collected
The compressed bookmark contained more than 8,000 characters. Its initial check used location.hostname.includes("fomo.family"), rather than strict domain matching. A hostname containing that string could therefore satisfy the check; execution was not restricted to the legitimate domain and its subdomains.
Importantly, opening the phishing website alone was not equivalent to running the credential-collection code. The bookmark needed to execute in a matching page context to access storage available to that page.
The script searched localStorage and sessionStorage for keys associated with authentication and wallet data, including terms such as privy, wallet, share, secret, seed, mnemon, turnkey, dynamic, fomo and mfa. When a key did not match, it checked the first 300 characters of the value. Matching values were retained up to 4,000 characters each.
It also enumerated accessible IndexedDB databases and read records from their object stores, with a four-second timeout for that collection process.
For authentication tokens, the script prioritized privy:token and privy:refresh_token, including token values wrapped in JSON. It then broadened its search while excluding fields such as id_token and identity. A final fallback looked for JWT-like strings beginning with eyJ; SlowMist cautioned that this could identify only suspected tokens, not guarantee valid credentials.
These targets matter because embedded-wallet access can depend on application authentication and locally stored wallet-related material. Their exposure may enable wallet takeover, private-key export or transactions, even without a conventional wallet-connection prompt. The report did not confirm which of those paths was used in this incident.
The MFA code was an attempt—not proof of enrollment
The script used a bearer token, Privy application ID and client ID to request account information from Privy’s /api/v1/users/me endpoint. It inspected the returned mfa_methods or mfaMethods array and included logic to retry after a 401 response using a refresh token.
Its MFA branch had a counterintuitive condition: it ran only when the account already had at least one MFA method. If the array was empty, that branch was skipped.
When triggered, the code created a nearly transparent 4-by-4-pixel iframe loading Privy’s embedded-wallets page and exchanged requests through postMessage. It attempted to initialize TOTP enrollment, obtain a secret or totpSecret, generate a six-digit code locally using 30-second time steps and HMAC-SHA1, and submit enrollment.
SlowMist explicitly distinguished this behavior from successful registration. Receiving an initialization secret does not establish that the server completed enrollment. Nor did the script’s treatment of errors containing words such as “already,” “exist,” “enrolled” or “duplicate” prove that a new secret became active.
Because the victim said MFA had not been enabled, SlowMist assessed that this branch probably did not run. Storage collection and credential exfiltration were independent of it, however, and could still proceed. Confirmation of any MFA change would require server-side records.
How data left the browser
The script organized collected information into storage, IndexedDB and MFA sections, then encoded it with base64url. If the encoded result exceeded 11,000 characters, it first reduced the IndexedDB content to wallet- and key-related records. If still too large, it narrowed the local-storage portion to privy:token, privy:refresh_token and mfa-session-storage. A separate 20-second fallback prevented collection from delaying transmission indefinitely.
The destination was noisy-heart-5856[.]zmfkc29[.]workers[.]dev. The code could send an obtained TOTP initialization secret early through fetch, and later redirect the browser with tokens, collected data, visitor and site identifiers, and any retained TOTP secret in URL parameters.
In non-destructive testing, SlowMist observed HTTP 302 redirects back to the phishing site for the root, unknown paths and requests containing credential parameters. POST /visit returned HTTP 204. Those responses were consistent with a collection-and-redirect design, but did not prove that the server stored the data.
A comment in fomo-track.js described a tracker → Cloudflare Worker → panel → Telegram chain. SlowMist treated that as a clue left by the sample’s author, not a verified backend architecture: it had no supporting evidence from the panel or Telegram.
What the fund tracing showed
Using MistTrack, SlowMist analyzed the reported recipient address:
D783JqupQ2FYhkxUfGEd1gaFEoAJDXRX1NEb4aVH2hZ6
The report said the address had been active since September 17 and already showed frequent USDC–SOL activity before the victim’s funds arrived. SlowMist inferred that there might have been other victims; that was not confirmed.
The address repeatedly exchanged USDC and SOL, mostly through Jupiter Aggregator, and distributed funds across numerous intermediate addresses. Some USDC was also split and transferred directly.
The report identified Relay.link transfers including:
- 0.6 SOL → 0.024 ETH;
- 0.59 SOL → 0.025 ETH;
- 0.29 SOL → 0.012 ETH;
- 0.29 SOL → 0.00039 BTC.
The three ETH transfers went to 0x77bd56dfef9530ba61962a420e34a0dbd55de51c; the BTC transfer went to bc1q6j54xfvlgqjw6mq2ja3pym3qrezp8k39aeftxh.
The address also received funds through deBridge, including a conversion from USDG on Robinhood’s chain into USDC on Solana, and a USDC transfer from BNB Chain.
Across the address’s overall activity, SlowMist reported 1,568.33 SOL sent to Privacy Cash Pool, which it described as the address’s principal laundering outlet. Some funds reached addresses associated with Stake and Winna. The Winna-related activity included deposits of 11.34 SOL and 1,500 USDC, and receipt of 7,199.81 USDC from a Winna hot wallet.
These observations describe the address’s broader activity. They do not establish that every listed transfer involved this victim’s funds. Whether stolen credentials were replayed, who initiated the subsequent transactions, and exactly how wallet control was obtained remained unresolved pending server logs and further on-chain analysis.
Indicators for investigation
The report listed these phishing and exfiltration indicators, defanged here:
hxxps://voltage[.]family/apphxxps://voltage[.]family/app/livenoisy-heart-5856[.]zmfkc29[.]workers[.]dev
It also supplied the following SHA-256 sample hashes:
| Sample | SHA-256 |
|---|---|
index.html |
24df225d70e399fa30a2d0761e8645e339d99a0f751af6f9e5e00ab555e2fa07 |
fomo-track.js |
6d771096e442b36b0719a4e07b19c62a5a985005e8a07ab5d50dd6ca59c4ad06 |
VerifyRoute |
d5576bb50cb299d0c48657ed0cfd3f03b4c2313db8b37abcee57f779d70f7f18 |
LiveTerminal |
193b305baf9548a6dded341f3dd613a811e4604c7dfa4447219664f6c43818f8 |
Security lessons for users and embedded-wallet teams
SlowMist advised users to stop when a purported verification process asks them to drag an icon into the bookmarks bar and execute it on a wallet or trading page. Users should inspect their bookmarks, remove unfamiliar javascript: entries and enable supported MFA.
Anyone who has executed a suspicious bookmark should use a trusted device and official channels to revoke abnormal sessions and relevant authorizations, inspect registered authenticators, and contact the platform. Users signing in through Google or another identity provider should also review that account’s security. A password change alone may not invalidate existing sessions or refresh tokens; that depends on the platform’s implementation.
Where there is evidence that a seed phrase or private key has leaked, SlowMist recommended moving remaining assets to a newly generated wallet. Preserving page addresses, bookmark contents, timestamps and transaction records can assist an investigation.
For developers, the report recommended independent verification and risk controls for MFA enrollment, replacement and recovery, as well as fund transfers. Existing sessions should not be the sole basis for sensitive security changes. It also called for session-management and revocation tools, alerts for abnormal devices and MFA changes, reduced exposure of long-lived credentials in client storage, and closer review of external links and user-generated content.
The central distinction is straightforward: the analyzed bookmark demonstrates a credential-theft mechanism, not a confirmed private-key-export or transaction-signing path. Avoiding seed-phrase entry and on-chain approval prompts does not, by itself, protect an embedded wallet from compromised application credentials.
Source: SlowMist’s original investigation, by Yao & Lisa, edited by 77. Original publication: October 8, 2026, 19:00 UTC+8.