On this page
An unfamiliar NFT or token appears in your wallet. Its image, name or transaction memo directs you to a website to claim a reward. The important question is what you do next: receive an asset, open a link, connect a wallet, grant a permission, sign a transaction or disclose a seed phrase. Those are different events, and a useful investigation must not collapse them into “the airdrop hacked the wallet”.
Do not enter a seed phrase or private key into a reward page, and do not sign a request you do not understand. Verify the campaign through an independently located official channel. If you have already interacted, preserve the website, messages and transaction details and identify the access or permission involved before assuming that closing the page has removed the risk.
The 2025 IC3 report lists the FBI’s 3 June 2025 Hedera NFT-airdrop alert among its public announcements. That alert describes malicious reward links, including links in transaction memos, leading users to websites seeking security information. It is a specific warning about a method; the annual report does not supply a separate nationwide NFT-airdrop loss total. The broader cryptocurrency descriptor covers complaints with a virtual-currency reference and cannot be used as an airdrop-only statistic.
Receiving, connecting and authorising are not the same
A wallet interface can display unsolicited assets or messages. Their presence does not authenticate the sender, prove the quoted market value or establish that an account has already been compromised. A malicious site may imitate a familiar project and present a countdown, a valuable-looking reward or a purported verification step to induce the next action.
| Observed event | What to establish | Do not assume |
|---|---|---|
| Unsolicited asset or memo appears | Network, token or NFT identifier, incoming transaction and displayed link. | That receipt alone proves theft or an authentic reward. |
| Website opened | Full domain, redirects already recorded, downloads and information entered. | That all losses necessarily arose from a token approval. |
| Wallet connected | Which site and account were connected, and what later prompts appeared. | That connection is identical to granting every spending permission. |
| Transaction or signature approved | Network, transaction data or signed message, affected token, spender and permission. | That every signature is an immediate transfer, or that every signature is harmless. |
| Seed phrase or private key disclosed | Where and when disclosure happened; which accounts derive from or use the exposed secret. | That changing the wallet application’s password replaces the exposed key. |
The Hedera example should not be applied mechanically to Ethereum or every other network. Token permissions, account structures and wallet interfaces differ. Record the actual chain and asset rather than choosing a remedy from a logo or app name.
How a spending permission can become relevant
For ERC-20 tokens on Ethereum and compatible systems, the ERC-20 standard distinguishes a transfer from an approval and an allowance. An approved spender can use the relevant transfer mechanism within its authority. A later movement may therefore involve a previously granted permission rather than a new ordinary transfer initiated by the wallet holder.
Examine the token contract, approval event, spender, allowance and later transfer together. A matching token name is insufficient because unrelated contracts can use similar names. Do not infer from an approval alone that a private key was disclosed, and do not apply this ERC-20 explanation as a complete account of NFT operator permissions or every signed permit mechanism.
Ethereum’s token-access guidance also distinguishes disconnecting a website from revoking an on-chain allowance. Closing the browser or removing a wallet connection may leave that permission in place. Revocation addresses a particular permission; it does not reverse a completed transfer or make an exposed seed safe again. Use verified wallet or network guidance, not a “revoke now” link sent by the same suspicious contact.
Match the response to the exposure
If you only received an unsolicited item, avoid interacting with its links or contracts merely to remove it. Check your wallet provider’s genuine guidance for hiding or reporting spam. Do not pay a support contact to “clean” a wallet or send assets to a validation address.
If you approved a suspicious permission, identify it accurately and obtain reliable assistance to revoke or otherwise contain it where possible. If you disclosed a seed or key, treat the underlying secret as exposed and plan protection of remaining assets using a newly generated, independently secured wallet. A complex or valuable incident may involve an attacker monitoring the account; adding funds for fees or experimenting with transactions can create further loss. Use a competent, verified incident-response route rather than improvised instructions from unsolicited helpers.
If the event instead involved an exchange password, authentication code or remote-access installation, secure that account and device through the official provider. The containment questions are closer to phishing and account takeover than a simple token-allowance issue.
Build a record that can test the suspected mechanism
Preserve the incoming item or transaction identifier, the memo or advertisement, the complete site address and existing screenshots showing the surrounding context. Record what the wallet asked you to approve, if that record is available, and the time zone used. Keep originals securely; work from copies when annotating them. Never include seed phrases or private keys in a public report or evidence bundle.
List actual outbound transactions with network, asset contract where relevant, amount, source, destination, timestamp and full transaction hash. Include the earlier approval or signature evidence if known. Record transfers between your own accounts separately from suspected loss, and distinguish real token units from the value advertised for an unsolicited asset.
The FBI’s cryptocurrency victim guidance asks for transaction identifiers, addresses, amounts, times and the surrounding communications and websites. It encourages reporting with the information available rather than waiting for a perfect tracing package. A transaction trail can identify investigative leads; a destination address alone does not prove a person’s identity, knowledge or criminal intent.
After a loss, verify anyone offering help
An unsolicited message claiming to restore assets through a special wallet synchronisation tool can repeat the original attack. Ordinary transaction tracing uses public addresses and transaction records; do not give an unsolicited helper your seed phrase or access to remaining assets as a condition of tracing. Check the provider, scope of work, identity and claimed legal route independently. Our recovery-scam guide explains how impersonated lawyers and officials use prior loss information to appear credible.
Report to the appropriate local authority and service providers. An IC3 submission is also available to overseas victims, but does not itself compel a freeze or return. Where the record identifies a Turkish bank, exchange, suspect or reachable asset, the Turkey-connected recovery framework addresses the separate legal and attribution questions.
Sources and scope
Sources checked on 20 October 2026: the 2025 IC3 Annual Report, Appendix D and pages 61–62; the FBI’s Hedera airdrop warning; the ERC-20 standard; Ethereum’s allowance-revocation guide; and FBI victim-reporting guidance linked above. The stage and evidence comparison is an analytical framework, not a diagnosis of a particular transaction. For the report’s broader totals and limitations, see the IC3 statistics resource.
