ZeroTokens: Phishing Platform Gives Operators Real-Time Control of Attack Flow

ZeroTokens is a phishing platform built for financial institution impersonation at significant scale, combining reusable infrastructure with institution-specific verification sequences across dozens of financial brands. 

ZeroTokens operates less like a conventional phishing kit and more like a scam call center running through the target’s browser. A human operator watches each session unfold, sees information as the target enters it, and decides which prompt appears next. In parallel, the operator can use that information in a separate session with the genuine financial institution, coordinating the two interactions in near real time without proxying the bank.

That human-controlled model allows the interaction to extend well beyond a one-time credential capture. In the campaign we observed, attackers used ZeroTokens to attempt to collect multiple forms of sensitive identity and authorization information during the same interaction. 

In this blog, we trace the attack from delivery through live operator control, examine what ZeroTokens is designed to capture, and highlight the behaviors defenders can use to identify activity that falls outside familiar phishing patterns.

The Anatomy of a ZeroTokens Attack

How the Campaign Reached Targets

The campaign used ten sender domains—four .com and six .asia—all registered through the same registrar and aged for five to eleven months before use. None published a mail exchange (MX) record, meaning the domains could send email but were not configured to receive it.

Mail was sent through nine abused SendGrid accounts. The messages carried SendGrid’s DKIM signature and passed SPF, DKIM, and DMARC checks. Ten subject templates map one-to-one onto sender domains—one template per domain, no rotation.

The abused SendGrid accounts helped the messages avoid obvious technical red flags, while the lure was crafted to reduce suspicion on the recipient side. In the example below, the campaign used W-8BEN tax-documentation recertification, a legitimate process through which brokers may need to re-verify a customer’s identity. That context makes subsequent requests for a driver’s license, card number, and transaction password feel believable. The lure also self-selects its audience: because only holders of U.S. securities have a W-8BEN on file, the pretext is relevant to the recipients it targets.

Figure 1: The display name impersonates the broker, while the underlying sender address uses a throwaway domain. The blocked image is the broker’s genuine logo, hotlinked from its website.

The first email tells the recipient that their W-8BEN tax documentation requires review to keep account records current and directs them to an “official account service portal” to complete the update. Rather than threatening immediate suspension, it warns that some services, transactions, or account functions may be limited if the review is not completed, giving the lure a restrained, administrative tone.

Figure 2: A second W-8BEN template uses a different sender domain and similarly restrained language.

The second template uses the same underlying pretext but presents it as a reminder, asking the recipient to review and update their W-8BEN information. It similarly avoids overt urgency, warning only that outdated or incomplete documentation may eventually restrict certain account features or transactions—language that helps the message resemble a routine compliance notice rather than an obvious phishing lure.

Inside the Multi-Step Phishing Flow

The phishing site presents a high-fidelity imitation of the targeted financial institution, reproducing its branding along with details such as real Australian Business Number (ABN) and Australian Financial Services Licence (AFSL) text, genuine privacy language, and functional help links. Within that imitation, ZeroTokens can display up to eight different target-facing screens modeled on stages of the institution’s verification process.

The attack begins with a cloned sign-in page designed to capture the target’s login credentials.

Figure 3: A cloned broker sign-in page requests the target’s client ID and password.

As the target enters information, the phishing page reports the current stage and field values back to the platform. A live operator uses that visibility to control the progression, selecting which available screen to present next rather than sending every target through the same fixed sequence automatically.

In the captured CommSec flow, one of those screens requests identity verification information, including driver’s license and card details.

Figure 4: The identity-verification screen requests a driver’s license number, card number, and expiry date, with guidance showing where to find each value.

The next step moves into account verification. The target is asked to enter a six-digit SMS security code, giving the operator access to a time-sensitive OTP generated by the genuine institution.

Figure 5: Step 2 prompts the target to enter a six-digit SMS verification code.

The flow then shifts from code entry to app-based approval, instructing the target to confirm a login through the CommBank app. This gives the operator another way to guide the target through an authentication challenge as the interaction unfolds.

Figure 6: Step 3 instructs the target to confirm a login through the CommBank app.

The final step extends the collection beyond identity and authentication information to a separate trading credential.

Figure 7: The final step asks the target for a trading password, a separate credential used to authorize orders rather than sign in to the account.

The combination of driver’s license information, card details, and a trading password matches the information an institution requests when a withdrawal or payment-destination change is challenged. The result is a staged collection flow that can extend well beyond account credentials to identity and authorization information associated with higher-risk account activity.

A Live Data Relay in a Human-Controlled Attack Flow

ZeroTokens does not proxy the target’s session to the real financial institution. Instead, the attack runs through two coordinated workflows. ZeroTokens manages the target-facing phishing interaction, while the operator—or potentially a second person—uses the harvested information to interact separately with the actual institution.

Within ZeroTokens, the phishing page maintains a persistent WebSocket connection with the platform for the duration of the session. Unlike a conventional web request that ends after the server responds, a WebSocket keeps a two-way communication channel open. The page continuously reports session state, including the target’s current stage and field values as they are entered, while the operator sends commands back telling the page what to display next.

That near-real-time exchange lets the operator coordinate the phishing page with activity in a separate browser session at the real institution. For example, once a target’s username and password appear in the ZeroTokens session board, the operator—or a colleague—can use them to sign in to the genuine bank. If the bank sends the target a real SMS verification code, the operator can direct ZeroTokens to display the corresponding OTP prompt. When the target enters the code into the phishing page, it appears in the session board, where the operator can retrieve it and enter it into the real bank session before it expires.

In the live session list, each active target appears as a separate row, with columns corresponding to the information that particular phishing project is designed to collect. As the target enters data, those fields populate in the console, while a stage indicator shows which screen the target is currently viewing.

Figure 8: The session board shows each active target’s current stage and information entered into the phishing flow. All data shown is synthetic.

From that same interface, the operator can control how an individual session progresses, moving the target between different stages of the phishing flow based on how the interaction unfolds.

Figure 9: The per-session command menu controls which stage or response the target sees next.

If a verification step fails, the operator can use a corresponding failure command to display an error and prompt the target to try again, rather than letting the interaction end. This creates another opportunity to capture a usable verification code or response—a capability most commodity phishing kits lack.

When the collection process is complete, the operator can redirect the target to the institution’s actual website. Ending the interaction on a legitimate site can make the transition appear less suspicious.

ZeroTokens Scale and Operations

Platform Reach and Campaign Scale

ZeroTokens is configured for 53 financial institution brands across 14 locales, including banks and brokerages in Australia, Japan, South Korea, Germany, India, Canada, the United States, and other markets. Each brand project includes its own set of fields to collect information and commands to guide the target through that institution’s verification flow.

The platform also includes a separate set of 36 card-issuer brand keys tied to a simpler card-harvesting template. Rather than reproducing a unique verification flow for each issuer, these brands use the same basic collection model. Together, the two approaches allow ZeroTokens to support both institution-specific verification flows and more generic card harvesting through the same tool.

Exact-template hunting identified more than 45,000 messages sent to over 24,000 recipients across more than 700 organizations, with more than 24,000 messages sent on a single peak day. Our research found that 82.5% of affected organizations were associated with .au, and the campaign accounted for 71.4% of August’s attack-marked volume using this pretext.

How ZeroTokens Is Deployed and Operated

ZeroTokens centralizes the management of its phishing sites through the same console used to oversee the broader operation.

Figure 10: The deployment panel shows active phishing sites, their configuration and infrastructure status, and live session counts.

New phishing sites can be created from an existing site archive as well as reused backend and CDN infrastructure, making individual lure hosts relatively easy to replace. As a result, taking down a single host does little to disrupt the broader operation. The more durable assets are the sender infrastructure and abused email-service-provider accounts.

The console also has a simple account model, with only two roles: super_admin, which has full access, and operator, which is limited to the session board. That division resembles a staffing model more than a customer model, leading Abnormal researchers to assess that ZeroTokens is very likely in-house tooling for a single group rather than a rented service.

Our team recovered no operator identity, persona, handle, channel, wallet, or payment path. The console interface is Chinese throughout, but that is weak evidence on its own and is not sufficient to attribute the operation.

Taken together, the artifacts show that much of the operation’s investment is organizational rather than technically sophisticated. Aging domains requires months of patience. Mapping verification flows for 53 financial institutions requires research. Keeping a live operator console staffed across time zones requires people. Those investments in time, preparation, and staffing are central to how ZeroTokens operates, even though much of the underlying technical infrastructure is designed for reuse.

What Happens Beyond the Phishing Session

Collection, Not Cash-Out

ZeroTokens is built to collect information, not act inside a target’s financial account. Across the console’s 46 endpoints, platform templates, 403 field definitions, and 382 operator commands, researchers found functionality to manage the phishing operation and access harvested data, but none to initiate withdrawals or transfers, add payees, check balances, or place orders. In other words, ZeroTokens itself has no cash-out capability.

Any subsequent account activity therefore happens outside the platform, through the genuine financial institution. Based on the information ZeroTokens is designed to collect, Abnormal researchers assess withdrawal or payment redirection fraud as the most likely objective. Brokerage account manipulation or theft followed by liquidation also remains possible.

Signs of Follow-On Fraud

Although the session begins with a W-8BEN tax-recertification lure, the final screen tells the target that they have submitted an application for a pre-IPO share allocation. That subject appears nowhere in the campaign’s eleven email templates, the other target-facing screens, or the information ZeroTokens is configured to collect.

Figure 11: The final screen tells the target that a pre-IPO share-allocation application has been submitted.

This abrupt shift may be intended to set up a later investment scam—for example, a follow-up telling the target that they have been selected and asking them to remit funds. It also suggests related deployments could lead directly with the investment lure. Because our research did not observe that follow-on interaction, these are assessments based on the terminal page rather than confirmed downstream activity.

What Defenders Should Know

ZeroTokens combines technically credible delivery with a human-controlled phishing flow that can collect far more than login credentials. That makes detection and response less about a single malicious page or password reset and more about recognizing the campaign’s behavioral patterns and accounting for the full range of information a target may have disclosed.

Detection Guidance

For defenders and threat hunters, some of the most durable signals come from the campaign’s behavior rather than the wording or appearance of an individual phishing message:

• Send-only domains with no MX records. Every sender domain observed in this campaign lacked an MX record, indicating that it was not configured to receive email.

• A new sender repeatedly using one subject at volume. The observed sender domains had no prior history, and each was tied to a single subject template. That behavioral pattern can remain useful even if the attacker changes the wording of the lure.

• Email-service-provider account identifiers that persist across domain changes. Where those identifiers are visible, they can connect activity across campaigns even when the attacker rotates sender domains.

• Sequential collection of multiple types of sensitive information. Requests for information such as license details, card data, and a trading password as separate steps minutes apart from the same client can indicate a live, multi-step harvesting session rather than a one-time credential form.

Response Guidance

• Treat suspected compromise as broader than credential exposure. Assume that identity information, card details, and a trading password may have been disclosed alongside login credentials, and involve fraud and identity teams in addition to account-security responders.

• Do not assume a single verification attempt defines the full exposure. ZeroTokens can repeatedly prompt a target after a failed verification step, so responders should determine which screens the target saw and what information they provided during the interaction.

• Prepare targets for a potential follow-on investment lure. Warn anyone who reached the pre-IPO allocation screen that no legitimate application was submitted, and watch for related messages trying to continue that narrative.

• Prioritize operator-controlled infrastructure. Block known lure hosts and ZeroTokens platform domains rather than the shared CDN infrastructure in front of them, and report the abused SendGrid accounts used for delivery.

The Broader Implications of ZeroTokens

ZeroTokens shows how attackers can make phishing more adaptive without making the underlying technology dramatically more sophisticated. By keeping a human operator in the loop—and giving that operator the visibility and controls to steer each interaction in real time—the platform turns human judgment into a repeatable part of the attack infrastructure. That makes tailored, responsive phishing possible across many targets and financial brands without requiring every interaction to follow the same predetermined path.

This points to a broader challenge for defenders. Phishing can no longer always be treated as a single malicious page, credential prompt, or verification event. In an operator-controlled interaction, the attack can adapt as the target responds, expand into multiple forms of sensitive information, and continue outside the phishing platform entirely once it has collected the data.

That changes where defenders need to draw the boundaries of an attack. Effective detection and response require looking beyond individual lures to the infrastructure and behavioral patterns supporting the interaction, as well as the downstream exposure that can persist even after the phishing page disappears.

For additional insight into the attack landscape and analyses of other dark web tools, visit Abnormal Intelligence, our threat intelligence data and research hub.

Visit Abnormal Intelligence

---

Key Indicators

Operator-controlled infrastructure only. Shared CDN ranges and ESP infrastructure are excluded.