Look for cloned branding, misspelled domains, unexpected token symbols, suspicious memo data, abnormal approval prompts and wallets being nudged toward urgency or sync requests. Those signals matter because impersonation campaigns are designed to look routine until the user is already at the signing step.
What impersonation fraud usually looks like on-chain and in the wallet flow
impersonation fraud usually shows up as a mismatch between what the user thinks they are interacting with and what is actually being presented for signature. Cloned branding, similar-looking domains, fake support or project identities, and token pages that mimic legitimate assets are all designed to reduce suspicion. The scam often stays quiet until the final approval or sync step, where the user is prompted to grant access, connect a wallet, or sign a message that looks routine.
Watch for visual and behavioural cues together rather than treating any single sign as decisive. A polished landing page can still be fraudulent if the token symbol, contract address, memo field, or request wording does not align with the real project’s normal flow. The most dangerous variants are the ones that borrow trust from a known brand, then push the user into fast action before they check details.
Why suspicious token details and signing prompts matter
Token impersonation works because many users trust the interface more than the underlying transaction. Unexpected token symbols, unusual memo data, requests to import or sync wallets, and approval prompts that ask for broad permissions are all indicators that the interaction may be redirecting value or authority away from the intended recipient. In practice, the fraud is often not the token itself but the way the user is guided into authorising the wrong contract, wallet connection, or transfer path.
Abnormal urgency is a common pressure tactic. Messages that claim the account will be locked, rewards will expire, or support must be verified immediately are meant to suppress verification behaviour. If the request includes signing, approval, or connection permissions that do not match the user’s normal experience with that dApp or token, treat it as a potential impersonation attempt until proven otherwise.
For payment and transfer scams that imitate legitimate crypto activity, the Authorised Push Payment (APP) Fraud Guide is useful background because the same impersonation pattern shows up when scammers try to make a transfer feel ordinary and authorised.
How to confirm the request before a wallet is exposed
The practical test is whether the request survives independent verification outside the message thread, social post, or wallet popup. Check the contract address against the project’s official channels, compare the domain carefully, and confirm that the requested action matches the dApp’s expected behaviour. If the page asks for memo data, allowances, or wallet sync in a way that differs from the real service, that discrepancy is a strong warning sign.
Good verification also means slowing down at the decision point that fraudsters exploit. If the user is being asked to approve a token, connect a wallet, or sign a message that appears to create broad access, the safe response is to pause and confirm the exact purpose, destination, and scope of the request. When the interaction does not clearly explain why the approval is needed, the burden should be on the requester, not the user.
For readers who want a deeper look at how stolen or abused token material is used after compromise, Salesloft OAuth token breach and Internet Archive breach 2024 both illustrate how token misuse becomes persistent access when rotation and revocation lag behind the initial exposure.
Risk and Threat Considerations
Impersonation fraud is risky because the first visible sign is often the last safe chance to stop it. Once a victim signs a malicious approval or connects the wrong wallet, the attacker may be able to move value, request additional permissions, or keep reusing the trust relationship until it is revoked. The attack is especially effective when the scam copies a familiar brand or support flow closely enough that the user relies on pattern recognition instead of verification.
Failure mechanism: The scam succeeds when a cloned identity, fake support path, or misleading token prompt convinces the user to authorise a contract or wallet interaction that transfers value or access to the attacker.
Impact: The result can be direct theft, repeated draining through granted approvals, account compromise, or a secondary compromise if the impersonated flow is used to harvest additional credentials or session access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Wallet and token fraud often starts with exposed secrets or token material. |
| NHI-05 — Overprivileged NHI | Bad approvals and broad wallet permissions create excessive access for an impersonated flow. | |
| NHI-07 — Long-Lived Secrets | Persistent token access extends the damage window after impersonation succeeds. | |
| Recommendation — Scan for exposed credentials and revoke any token that can impersonate a wallet or dApp. Limit wallet approvals to the minimum scope and review any broad permission grant. Rotate or expire long-lived tokens and approvals before they can be reused. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and approval misuse depends on poor credential and token lifecycle control. |
| Recommendation — Enforce prompt revocation and rotation for any authenticator that can be replayed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Impersonation scams exploit weak trust in the authentication-looking flow around wallets and dApps. |
| Recommendation — Verify the authenticity of each token exchange and signed request before accepting it. | ||
Practitioner Guidance
What to verify: Validate the contract address, domain, token symbol, and signing intent independently of the message or interface that delivered the request. If any one of those four elements is inconsistent with the legitimate project, treat the request as suspect.
Escalation / exception: Escalate immediately when a user reports urgency, sync requests, unexpected approvals, or a support contact asking for wallet actions. Those are not minor UI issues, they are often the point where impersonation fraud becomes irreversible.
Practitioner takeaway: The most reliable signal is not a single visual clue, it is a mismatch between the claimed identity and the action being asked of the wallet. Train users to stop at that mismatch, because once the signature is granted, the fraud usually moves faster than the review process.
Related resources from NHI Mgmt Group
- How should organizations respond to OAuth token abuse incidents?
- How should teams respond when a service account token is exposed?
- Why do secrets stay dangerous even when they are no longer actively used?
- What are the signs that an online order stream is being used for fraud testing or account abuse?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org