NFT Security Guide: Avoiding Scams and Theft
Key Takeaways
- •To understand how NFT theft works mechanically, you need to understand how token approval permissions work on Ethereum and why they were designed this way.
- •The more dangerous evolution in NFT theft does not involve on-chain approval transactions at all.
- •New NFT launches are some of the most reliably exploited events in the space.
- •Before you sign a single transaction with an NFT contract — mint, approve, trade — verify it is legitimate.
- •Not all NFT scams extract money through direct wallet attacks.
- •An NFT rug pull follows the fundraising pattern: mint, promise, abandon.
Between January 2022 and December 2022, over $100 million worth of NFTs were stolen — not through sophisticated zero-day exploits or nation-state attacks, but through wallet approvals, forged signatures, and fake websites. The victims were not naive newcomers. Kevin Rose, founder of Digg and a well-known crypto figure, lost $1.1 million in NFTs in January 2023. Seth Green — an actor with a full security team — lost four Bored Apes in May 2022. Arthur Cheong, founder of DeFiance Capital, lost $1.7 million in NFTs in March 2022 through a targeted spear-phishing attack that exploited his documented interest in a specific NFT project.
The attacks are not technically sophisticated. They require one thing: a victim who signs something they do not understand. This guide explains what they are signing, why it transfers ownership, and how to stop it from happening to you.
Understanding the Ethereum Permission Model
To understand how NFT theft works mechanically, you need to understand how token approval permissions work on Ethereum and why they were designed this way.
NFT marketplaces — OpenSea, Blur, LooksRare, X2Y2 — need the ability to transfer your NFT from your wallet to a buyer's wallet when you make a sale. They cannot take custody of your assets (that would require trust and create liability). Instead, they ask you to sign an approval transaction granting them the right to transfer specific tokens, or all tokens from a collection, on your behalf.
There are two approval functions defined in the ERC-721 standard:
interface IERC721 {
// Approve a specific address to transfer one specific token
function approve(address to, uint256 tokenId) external;
// Approve an "operator" to transfer ANY token you own from this collection
// operator = a marketplace contract address
// approved = true to grant, false to revoke
function setApprovalForAll(address operator, bool approved) external;
// Read-only check
function isApprovedForAll(
address owner,
address operator
) external view returns (bool);
}When you call setApprovalForAll(operator, true), you are granting the operator address — typically a smart contract — unrestricted ability to transfer any NFT you own from that collection, at any time in the future, without further authorization.
Three characteristics make this dangerous:
The approval is permanent. It persists until you explicitly revoke it. You grant it once when you first list on OpenSea, and it stays active for years unless you call setApprovalForAll(operator, false). Most holders never revoke old approvals.
The approval covers all tokens. Not just the one you are selling. If you own BAYC #100 through #105 and grant OpenSea approval for the BAYC collection, you have approved the transfer of all six.
The approval is contract-level, not platform-level. You are approving a specific contract address. If that contract is exploited, or if you are tricked into approving a malicious contract that impersonates a legitimate one, all your tokens are at risk.
The Attack Flow
1. Attacker creates a malicious contract that looks like a legitimate marketplace
2. Victim visits a site that presents a transaction to sign
3. Wallet displays: "setApprovalForAll — approve operator 0x[attacker] for collection 0x[BAYC]"
4. Victim clicks Confirm — sees it as "connecting to marketplace"
5. Attacker calls transferFrom() on their contract, pulling all victim's BAYC tokens
6. Tokens are immediately listed on OpenSea through a different wallet
7. Sold within minutes. Proceeds sent through Tornado Cash or cross-chain bridge.
8. Irreversible.
The BAYC Instagram hack on April 25, 2022 executed this exactly. The attacker compromised BAYC's Instagram account (134,000 followers). Posted a link to a fake "land airdrop" promotion — a "claimable" piece of Otherside metaverse land. Holders connected wallets and signed an setApprovalForAll transaction. Approximately 91 NFTs were drained in the first 30 minutes: 24 BAYC, 30 MAYC, 7 CloneX, and others. Total stolen: approximately $2.8 million at the time. The attacker's address received the tokens within seconds and flipped them on the same marketplaces the victims had previously listed on.
Never grant setApprovalForAll to any contract you did not manually verify against a protocol's official documentation. Any website offering free NFTs, airdrops, "land claims," or claiming you need to "migrate" your tokens to a new contract is almost certainly attempting to steal your approvals. The legitimate version of these events does not require setApprovalForAll.
Signature-Based Attacks: The Silent Drain
The more dangerous evolution in NFT theft does not involve on-chain approval transactions at all. It uses off-chain signatures — cryptographic proofs signed by your wallet that authorize transfers without touching the blockchain until the attacker executes them. No gas cost. No entry in your transaction history. Nothing to see until the tokens are gone.
How OpenSea's Seaport Protocol Works
OpenSea's Seaport protocol (deployed May 2022) uses off-chain signed orders. When you list an NFT, you do not send a transaction — you sign a structured message that says:
"I, wallet 0xYours, agree to exchange token ID 1234 from contract 0xBAYC for 50 ETH. This offer is valid until timestamp 1735689600."
This signed message is stored on OpenSea's servers. When a buyer accepts, OpenSea submits the order on-chain. Your signature authorizes the transfer.
An attacker can present you a forged version of this structure. If you sign it, you have created a valid cryptographic proof authorizing the transfer of your NFT for whatever price the attacker specified — which might be 0.0001 ETH, or 1 WEI.
// What a malicious Seaport order looks like (simplified)
// The WEBSITE shows you "Confirm listing for 50 ETH"
// Your WALLET is actually signing this:
{
"offerer": "0xYourWalletAddress",
"offer": [
{
"itemType": 2, // ERC721
"token": "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D", // BAYC contract
"identifierOrCriteria": "1234", // Your BAYC #1234
"startAmount": "1",
"endAmount": "1"
}
],
"consideration": [
{
"itemType": 0, // ETH
"token": "0x0000000000000000000000000000000000000000",
"startAmount": "1", // 1 WEI — essentially free
"endAmount": "1",
"recipient": "0xAttackerAddress"
}
],
"startTime": "1700000000",
"endTime": "1735689600", // Valid for months
"orderType": 0,
"zone": "0x0000000000000000000000000000000000000000",
"zoneHash": "0x0000...0000",
"salt": "77777777777",
"conduitKey": "0x0000...0000",
"counter": 0
}Kevin Rose's $1.1 million loss in January 2023 was this attack precisely. The attacker found Rose on a phishing site, presented him with what appeared to be a routine signature request. Rose signed. The signature was a valid Seaport order authorizing bulk transfer of 40 Chromie Squiggles and other pieces for minimal value. The attacker executed on-chain. Everything was gone within two minutes of signing.
What Malicious Sites Use to Trigger These Signatures
Attackers use several techniques to get legitimate-looking signature popups to appear:
Fake OpenSea listing interface. A pixel-perfect clone of the OpenSea listing modal. The "price" field shows whatever the victim expects. The underlying signed structure contains 0.001 ETH.
"Verify ownership" requests. Sites claiming you need to verify wallet ownership before receiving an airdrop. The "verification" is actually a Seaport signature.
Approval "migration" flows. "OpenSea is upgrading. Sign here to migrate your approvals to the new contract." There is no upgrade. There is an attacker-controlled contract.
Fake Blur blur.io competition sites. During Blur's ascent in late 2022 and 2023, dozens of fake blur.io lookalike sites ran Google Ads and appeared above the real site in search results.
Permit Signatures for NFTs
EIP-4494 introduced a permit() function for NFT approvals — analogous to EIP-2612's permit for ERC-20 tokens. It allows setApprovalForAll to happen through an off-chain signature rather than an on-chain transaction.
// EIP-4494 permit signature enables approval without gas
function permit(
address spender,
uint256 tokenId,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) external;The practical implication: an attacker who obtains a Permit signature from you can grant themselves setApprovalForAll silently, with no on-chain trace until they execute the transfer. There is no approval transaction in your history to notice.
Defense Against Signature Attacks
The only reliable defense is reading what you are signing before you sign it.
Hardware wallets display structured data. A Ledger or Trezor, when asked to sign an EIP-712 typed data structure, displays the decoded fields: offerer, offer[0].token, offer[0].identifierOrCriteria, consideration[0].startAmount, consideration[0].recipient. Read these. If consideration[0].startAmount is "1" when you expect it to be "50000000000000000000" (50 ETH in wei), something is wrong.
Rabby Wallet pre-simulates transactions. Rabby's built-in security scanner simulates the effect of every transaction and signature before you sign, showing you what assets will move and where. It flags suspicious structures. It is not perfect, but it catches most common attack patterns.
Wallet Guard and Pocket Universe. Browser extensions that hook into MetaMask and add a pre-execution simulation layer. They flag malicious signatures with a red screen before you confirm. Both are free.
Never sign from a link in a DM, email, or notification. Every phishing attack requires you to navigate to the attacker's domain. You will not navigate there on your own — you need to be directed. Treat every link you receive as suspect.
Fake Minting Sites: The Google Ads Trap
New NFT launches are some of the most reliably exploited events in the space. The attack is mechanically simple and nearly cost-free to execute:
Day 0 (before mint announcement): Attacker registers lookalike domains for projects they expect to mint. If the real site is projectname.xyz, they register projectname-mint.xyz, mint-projectname.com, projectnameofficial.xyz. Cost: $10-30 per domain.
Day 1 (mint announced): Attacker deploys a pixel-perfect clone of the project's site. The clone's "Mint" button calls a malicious contract that either drains ETH directly or calls setApprovalForAll on existing collections.
Day 2 (mint day): Attacker runs Google Ads on search terms for the project name. The fake site appears above the real site in search results, clearly labeled "Ad" in small print that most users ignore. Users land on the fake site, connect wallets, and are robbed.
Months later: The fake site continues catching stragglers who find it through search. Unlike the attackers, who move on after mint day, the infrastructure sits and waits. Fake minting sites have been documented running successfully for 8-12 months after launch.
Real-World Scale
During the Otherdeed for Otherside land sale (May 2022), which processed over $318 million in primary sales, at least seven confirmed fake minting domains were operational. All ran Google Ads. The real site had to post prominent warnings. Several victims who connected wallets to fake sites lost their entire existing BAYC/MAYC holdings through setApprovalForAll attacks triggered by the fake "mint" flow — not just the ETH they intended to spend on the mint.
How to Verify the Real Mint Site
There is exactly one reliable way to find an NFT project's official mint URL:
- Go to the project's verified Twitter account (blue checkmark, long history)
- Find the pinned announcement or most recent mint announcement
- The URL in that tweet is the official URL
- Bookmark it on the day it is posted
- On mint day, navigate to your bookmark — do not search
Do not use Google. Do not follow links from Discord DMs, even from accounts that appear legitimate. Discord accounts are routinely compromised and used to post fake mint links. A server admin's compromised account posting "Official mint is live: [fake URL]" in the announcements channel has stolen millions of dollars.
If a project does not have a verified Twitter account with a documented history, the mint URL cannot be trusted. Do not mint from projects where you cannot independently verify the URL through multiple official channels.
Verifying an NFT Contract Before Interacting
Before you sign a single transaction with an NFT contract — mint, approve, trade — verify it is legitimate. This takes under five minutes and eliminates the risk of interacting with a malicious contract.
Step 1: Find the Authoritative Contract Address
The official contract address should appear in at least two of these sources:
- The project's official website (already verified through the process above)
- The project's pinned Twitter or Discord announcement
- The project's documentation or FAQ
Reject any contract address provided through:
- A DM (Discord, Twitter, Telegram) — even from apparently legitimate accounts
- A search result or advertisement
- A site you navigated to through a notification or email link
- A Discord bot or verification bot
Cross-reference addresses from at least two independent sources.
Step 2: Audit the Contract on Etherscan
Navigate to etherscan.io and paste the contract address.
Verify source code is published. The green checkmark next to the contract address means the source code is verified — it was published by the deployer and Etherscan has confirmed it matches the deployed bytecode. If the source code is not verified, you cannot read what the contract does. Treat unverified contracts as hostile until proven otherwise.
etherscan.io/address/0x[contract-address]#code
Check deployment date. Click the contract address, then look at the "Contract Creator" field and the first transaction. A contract deployed 12 hours ago claiming to be the official mint for a months-old project is a red flag. A contract deployed the same day as the project's announced mint is consistent with legitimacy — but still verify everything else.
Read the functions. Under the "Read Contract" and "Write Contract" tabs, you can see every public function. Look for any of these red flags:
// Red flag 1: Owner can transfer any token without approval
function adminTransfer(address from, address to, uint256 tokenId)
external onlyOwner {
_transfer(from, to, tokenId); // Owner steals any holder's NFT
}
// Red flag 2: Arbitrary ETH drain function
function withdrawAll() external onlyOwner {
payable(owner()).transfer(address(this).balance); // Fine for mint proceeds
// But does it also drain user deposits? Check the full logic.
}
// Red flag 3: Upgradeable proxy without timelock
// Proxy admin can swap the implementation contract immediately
// Check if there is a 48-72 hour timelock on upgradesCheck the transaction history. Do other people's mint transactions appear? Are the ETH amounts consistent with the announced mint price? An empty transaction history or transactions with amounts that don't match the announced price are suspicious.
Step 3: Verify Audit Coverage
Legitimate projects with significant primary sales value get their contracts audited before launch. Check the project's documentation, Discord, and Twitter for links to audit reports. Auditors who regularly cover NFT contracts include Trail of Bits, Certik, OpenZeppelin, and Spearbit.
A freshly deployed contract with no audit history for a project claiming to be major is highly suspicious. Compare contract deployment date with audit report dates — a contract deployed before the audit was completed means changes may have been made post-audit.
The Revoke.cash tool (revoke.cash) displays every active token approval for your wallet address. Run this audit quarterly, and run it immediately after any minting session or interaction with a new protocol. For each approval, check: do I recognize this operator address? Is this a protocol I still use? If you cannot answer yes to both, revoke it. Each un-revoked approval from a protocol you no longer use is a standing liability.
Wash Trading and Manufactured Rarity
Not all NFT scams extract money through direct wallet attacks. Some manipulate market perception to manufacture artificial value.
Wash Trading Mechanics
Wash trading involves trading an NFT between wallets controlled by the same entity to create a fabricated transaction history with an inflated price.
The typical sequence:
- Attacker mints or buys an NFT cheaply
- Transfers it to Wallet B for 5 ETH (attacker controls both wallets)
- Transfers it back from Wallet B to Wallet C for 8 ETH
- Lists it for sale at 12 ETH with a clean-looking price history
A genuine buyer, seeing what appears to be organic trading volume and a rising price trend, purchases at 12 ETH. The attacker pockets 12 ETH (minus the 13 ETH spent in fake trades, plus whatever they originally paid — the economics only work when the final sale price significantly exceeds the wash trading setup cost, which it often does because gas fees for NFT transfers were low during the period when most wash trading occurred).
A 2022 Chainalysis report found that a single address conducted $8.9 million in NFT wash trading on OpenSea. Nansen research identified that 262 traders on LooksRare wash-traded $8.3 billion in volume over the platform's first several months — largely to farm the platform's LOOKS token rewards, which paid out based on trading volume.
Detection: In the transaction history, check the buyer and seller wallet addresses. If the same wallet addresses appear repeatedly on both sides of multiple trades, that is wash trading. Check wallet ages on Etherscan — wash traders often use fresh wallets with no other activity outside the wash trading. Tools like NFTnerds.ai and Icy.tools flag suspicious volume patterns.
PMKID-Style Trait Manipulation
A more subtle scam involves deploying a collection where the smart contract's metadata function can be modified post-mint to change trait rarity — making common tokens appear rare and valuable, or demoting rare tokens to ordinary.
If an NFT's on-chain metadata points to an off-chain server (e.g., tokenURI returns https://api.project.com/token/123), the project team can silently update that server to change traits. The image and attributes your wallet shows are not guaranteed to reflect what was promised at mint.
Fully on-chain metadata (stored in the contract itself, often in base64-encoded SVG) is immune to this. Projects like Nouns, Loot, and Art Blocks Art Blocks Curated store everything on-chain.
Rug Pulls: When the Team Is the Attack
An NFT rug pull follows the fundraising pattern: mint, promise, abandon.
The team sells NFTs with a roadmap that promises utility — a game, a token airdrop, exclusive events, metaverse integration, derivative project rights. Buyers purchase the NFTs for the promises, not just the art. Once the team has raised enough (and before the community loses patience), they go dark.
What distinguishes NFT rug pulls from DeFi rug pulls is that many of them involve genuine artistic output and sophisticated marketing. The theft is in the promised utility, not the collection itself.
Documented Cases
Frosties (January 2022): Ethan Nguyen ("Frostie") and Andre Llacuna raised $1.3 million in an NFT mint and abandoned the project within hours of the mint selling out. Discord went offline. Twitter went dark. The wallets moved funds through mixer services. In March 2022, the DOJ arrested both — they became among the first people charged federally with NFT-specific fraud. Nguyen was sentenced to 20 months in federal prison in February 2023.
Evolved Apes (October 2021): "Evil Ape," the pseudonymous developer, raised approximately 798 ETH (~$2.7 million at the time) and disappeared with the mint proceeds. The project's smart contract had a standard admin withdraw function. Evil Ape called it. Gone.
Big Daddy Ape Club (January 2022): Raised $1.3 million. Rug pulled within 24 hours of mint.
Fomo Mofos (March 2022): Raised 1,000 ETH ($3 million). Rug pulled same day.
The pattern repeats because the barrier is low and the legal consequences were, until recently, nearly nonexistent. That has begun to change — the DOJ's NFT fraud prosecutions have accelerated since 2022.
Evaluating Project Legitimacy Before Minting
Team doxxing. Has the team revealed their real identities? Pseudonymous teams are not automatically suspect — many legitimate projects operate anonymously — but a doxxed team faces real consequences for fraud that a pseudonymous one does not.
Prior track record. Has this team shipped anything before? Have the founders participated in previous NFT or crypto projects with verifiable outcomes? A first project with ambitious utility promises from an anonymous team is maximum risk.
Smart contract audit. Is the contract audited? Is the audit from a recognized firm? Does the audit cover the specific functions used in the project (minting, royalties, utility distribution)? An audit that only reviewed the ERC-721 base and not the project-specific functions is less useful.
Retained admin powers. Read the contract. Does the team retain any of these:
- Ability to change token URI metadata
- Ability to pause transfers
- Ability to change royalty recipients
- Ability to mint additional tokens after sale
- Unrestricted ETH withdrawal functions
Some of these are legitimate (royalty management), some are red flags (unlimited additional minting). Understand what powers the team keeps after the mint.
Revenue in escrow or vesting. Does the smart contract hold mint proceeds and release them based on a vesting schedule or milestone completion? Or does the team have immediate access to all mint revenue? Immediate access is the norm, but it is also the precondition for a rug pull.
The Seth Green Case: IP Complexity of NFT Theft
The Seth Green theft in May 2022 illustrates that NFT theft creates complications beyond financial loss that are not fully resolved by legal frameworks.
Green, an actor and creator, owned four BAYC NFTs including BAYC #8398. He had publicly announced plans to use BAYC #8398 as the lead character in an animated TV show he was developing ("White Horse Tavern"). The character — a BAYC ape he had named "Fred Simian" — was the show's central figure.
Through a phishing attack, Green lost all four NFTs. BAYC #8398 was subsequently purchased by a third party ("DarkWing84") who appeared unaware it was stolen.
Bored Ape Yacht Club grants commercial rights for a token to whoever holds the token. When the token changed hands through the exploit, the commercial rights — including the rights to the character Green had built — theoretically transferred to DarkWing84.
This created a situation where Green had developed a character, written scripts, done voice work, and announced a production — but no longer held the rights to the underlying IP that the show was built around. He eventually paid approximately $297,000 to buy BAYC #8398 back from DarkWing84 (who had purchased it on the secondary market at floor price, unaware of the stolen status).
The takeaway: for NFTs with commercial rights attached, the financial loss from theft is only part of the damage. Business continuity, IP rights, and creative projects built on holder status all become liabilities.
Cold Storage for NFTs: Moving Valuable Holdings Off Hot Wallets
A "hot wallet" is any wallet connected to the internet and used for regular transactions — MetaMask, Coinbase Wallet, Phantom. These wallets are exposed to every site you interact with, every signature request you approve, and every approval you have ever granted.
A "cold wallet" is a hardware wallet — a physical device (Ledger Nano X, Trezor Model T, Keystone Pro) that stores your private key offline. The key never leaves the device. Every transaction must be physically confirmed on the device itself. A phishing site that tricks you into presenting a malicious signature request cannot execute it without you physically pressing a button on the hardware device — which displays the actual transaction details, not the website's representation of them.
Moving NFTs to Cold Storage
1. Acquire a hardware wallet from the manufacturer's official website only
(Not Amazon — counterfeit Ledgers with backdoored firmware have been sold)
2. Initialize it on the device itself, following manufacturer instructions
3. Write the 24-word seed phrase on paper — never digital, never photographed
4. Store the seed phrase in a physically secure location (safe, safety deposit box)
5. In MetaMask or your current wallet, initiate a transfer to the hardware wallet address
(Transfer a small test amount first and verify it arrives before moving everything)
6. Verify the transfer on the blockchain (Etherscan)
7. Disconnect the hardware wallet when not in use
Ledger and Trezor both support ERC-721 (NFT) transfers through their hardware interfaces. Ledger Live allows you to view and transfer NFTs. For full functionality including marketplace listings, you can connect the hardware wallet to MetaMask — the hardware wallet signs each transaction, but you can still interact with Blur or OpenSea.
The operational model for high-value holdings:
- Cold storage wallet (hardware): Stores valuable NFTs and main ETH holdings. Never connected to DeFi protocols or new sites. Only used for transfers to/from the hot wallet.
- Hot wallet (MetaMask): Connected to DeFi and marketplaces. Holds only what is needed for active use. If compromised, losses are bounded to what you deliberately placed there.
- Dedicated minting wallet: Funded only with enough ETH for the specific mint. No existing valuable holdings. Grant approvals here and revoke them after the mint.
Ledger's February 2022 firmware update added "Clear Signing" support — a feature that decodes and displays the human-readable details of EIP-712 typed data signatures on the device screen, rather than showing raw hex. This is exactly what you need to see through malicious Seaport orders. Make sure your Ledger firmware is current. Older firmware displays EIP-712 signatures as unreadable hex, which makes it impossible to distinguish a legitimate listing from a malicious one.
The Kevin Rose Attack: Technical Breakdown
The Kevin Rose theft in January 2023 is worth a detailed breakdown because it represents the current state-of-the-art in NFT social engineering.
Rose had significant public exposure — a podcast, a public Ethereum address traceable to his on-chain history, documented interest in generative art (particularly Art Blocks Chromie Squiggles). His holdings were publicly visible to anyone who looked at his wallet address.
The attack flow reconstructed from on-chain data and Rose's own post-incident disclosure:
1. Target selection and research. The attacker identified Rose as a target based on his public ENS name, his holdings visible on-chain, and his known interest in Chromie Squiggles (where his wallet held 40 of them — a collection worth approximately $750,000 at the time).
2. Initial contact. Rose received an invite to "review an unreleased NFT project" through a channel associated with someone he knew, with apparent social proof. This is the pattern: attackers compromise adjacent accounts or create convincing proxies.
3. The malicious signature. The site presented Rose with what appeared to be a routine signature request — likely framed as "verify your wallet to view the unreleased collection" or similar. The underlying signature was a Seaport order authorizing the bulk transfer of his NFT holdings.
4. Execution. Within minutes of Rose signing, the attacker submitted the signed order on-chain. 40 Chromie Squiggles (floor price approximately $25,000-$30,000 each at the time) and other pieces transferred out. Rose posted about the incident in real time as he watched his wallet drain.
5. Laundering. Tokens were sold through multiple marketplace transactions, proceeds bridged and mixed.
Total loss: Over $1.1 million in NFTs.
Rose has since said he believed the signature was routine "access control" for viewing a private collection. He was using MetaMask, which at the time did not decode EIP-712 typed data in a readable way. He saw hex strings. He signed.
This is the crux: the technology to prevent this attack existed (hardware wallets with clear signing, Rabby wallet with pre-simulation) but was not in use. Social engineering defeated technical controls not through sophistication, but through the gap between what the wallet displayed and what was actually being signed.
Social Engineering: Discord, Twitter DMs, and Fake Community
The technical exploits above all require one prerequisite: getting the victim to a site they would not otherwise visit. Social engineering is how they get there.
Discord Server Compromise
Discord is the primary communication channel for NFT communities. A compromised Discord server — or a fake server that looks like the real one — is among the most reliable vectors for distributing phishing links to a targeted community.
How servers get compromised:
- Discord phishing bots that steal session tokens from moderators through fake "verification" flows
- Stolen moderator credentials through credential stuffing (password reuse from data breaches)
- Social engineering against Discord staff or moderators
- Fake Discord support DMs that harvest admin credentials
Once a moderator's account is compromised, the attacker posts in announcement channels (which appear official and credible), DMs server members with "emergency" notifications about mints or security issues, and creates bot-generated spam in general channels pushing the malicious link.
Defense: Before clicking any link from a Discord announcement, verify it against the project's official Twitter. A Discord announcement that is not corroborated by a corresponding tweet from the project's verified account should be treated as potentially fraudulent — particularly if it involves urgency, a limited time window, or an "exclusive" opportunity.
Twitter/X Impersonation
Attackers create near-identical copies of verified NFT project accounts, changing one character in the username and posting from there. During a genuine mint, a fake account with 500 followers posting identical content to the real account will catch some victims, especially those who find the fake account through promoted tweets.
Always verify the account handle character by character. A verified blue checkmark on Twitter since the API change in 2023 only means someone paid $8/month — not that they are the project's official account.
"Collab" and Access Requests
Attackers reach targets through professional-appearing requests: "We want to feature your collection," "We're doing a collaborative project," "Can we schedule a wallet presentation for our community?" The request seems legitimate and goes through normal channels. The malicious payload comes later, once the target has been engaged and lowered their guard.
Arthur Cheong of DeFiance Capital lost $1.7 million in NFTs through exactly this attack in March 2022. He received a legitimate-looking PDF from a known contact in the space. The PDF contained a malicious script that exploited a then-active vulnerability in PDF rendering. The script established a foothold, and from there the attacker accessed his browser's wallet extension storage.
This is the spear-phishing tier: carefully targeted, using real relationships and prior research. Defense requires technical controls (dedicated hardware wallets, browser isolation for sensitive operations) not just social awareness.
The Arthur Cheong Attack: A Lesson in Compartmentalization
Cheong's March 2022 attack is worth understanding because it represents a more sophisticated tier than the average NFT phishing attempt.
The attack vector was a malicious PDF sent via email from a known contact whose account had been compromised. The PDF exploited CVE-2022-30190 (Follina), a Windows MSHTML remote code execution vulnerability that Microsoft had not yet patched at the time of the attack.
The malicious PDF dropped a stealer that extracted browser extension storage — which is where MetaMask stores encrypted private keys and session data. With the MetaMask session data, the attacker was able to execute transactions from Cheong's wallets.
Losses included approximately 78 NFTs from multiple collections plus 1 million $LOOKS tokens, totaling approximately $1.7 million.
The lessons:
- PDF files received via email or Telegram are code execution vectors, not just documents — treat them accordingly
- Browser-based wallets (MetaMask, Phantom) store sensitive data in your browser profile, which is accessible to malware with user-level access
- Compartmentalization: a hardware wallet for valuable assets would have blocked the final step — no malware can approve transactions without physical hardware interaction
Building a Secure NFT Operations Setup
Based on the attack patterns above, here is the operational security architecture that actually reduces risk.
Wallet Architecture
Cold Storage Wallet (Ledger/Trezor)
├── Primary ETH address with hardware key
├── Holds: all NFTs not currently listed for sale
├── Holds: ETH holdings above "working capital" threshold
├── Connected to: nothing, no dApps, no approvals
└── Accessed: rarely, only for transfers to/from hot wallet
Hot Wallet (MetaMask + Ledger via USB)
├── Hardware wallet connected to MetaMask as hardware signer
├── Holds: ETH needed for current operations (1-5 ETH maximum)
├── Connected to: Blur, OpenSea, Uniswap (legitimate protocols only)
└── Accessed: daily trading and listing activity
Dedicated Minting Wallet (MetaMask, software key acceptable)
├── Holds: only the ETH needed for the specific mint
├── No existing NFT holdings
├── Connected to: minting contract only, then revoked
└── Principle: if this wallet is drained, losses are bounded to current mint ETH
Browser Setup for Web3 Operations
- Use a dedicated browser (Firefox or Brave) exclusively for web3/NFT operations
- No extensions except MetaMask and Wallet Guard/Pocket Universe
- Clear browser data after minting sessions
- Never use this browser for email, social media, or other activities
- Install Rabby Wallet as an alternative to MetaMask — it provides transaction pre-simulation and shows you what will move before you confirm
Regular Approval Audits
Run this audit monthly:
- Navigate to revoke.cash or etherscan.io/tokenapprovalchecker
- Connect your wallet
- Review every
setApprovalForAllapproval listed - For each: recognize the operator address? Still use this protocol?
- Revoke everything you cannot immediately justify
# Common operator addresses you SHOULD see (legitimate)
OpenSea Seaport 1.5: 0x00000000000000ADc04C56Bf30aC9d3c0aAF14dC
Blur Marketplace: 0x00000000000111AbE46ff893f3B2fdF1F759a8A8
LooksRare Exchange: 0x59728544B08AB483533076417FbBB2fD0B17CE3C
# What you SHOULD NOT see
Any address that is not a major recognized marketplace
Any contract deployed in the last week
Any contract with no verified source code on Etherscan
Pre-Mint Security Checklist
Before connecting your wallet to any NFT project:
- [ ] Located the official mint URL from the project's verified Twitter account only — not search results, not Discord DMs
- [ ] Confirmed the contract address matches what is published in the pinned announcement
- [ ] Verified the contract is deployed and source code is verified on Etherscan with green checkmark
- [ ] Contract was deployed at least 24 hours ago (gives community time to identify problems)
- [ ] Read the Write Contract functions — no suspicious admin powers (arbitrary transfer, unlimited mint, unilateral metadata change)
- [ ] Checked for an audit report from a recognized firm
- [ ] Using a dedicated minting wallet with only the required ETH and no other holdings
- [ ] Hardware wallet connected with latest firmware (for Ledger: 2.1.0 or later for clear signing support)
- [ ] Rabby Wallet or Wallet Guard active in browser to pre-simulate the mint transaction
- [ ] Already have Revoke.cash bookmarked to audit approvals after the mint
- [ ] SSID of my WiFi is not broadcasting from a compromised device on the same network
After the mint:
- [ ] Verified the NFT arrived in the expected wallet
- [ ] Revoked the approval granted to the minting contract via Revoke.cash
- [ ] If the NFT is valuable: transferred to cold storage hardware wallet
- [ ] Did NOT share my transaction hash on Twitter until the approval was revoked (transaction hash leaks wallet address to anyone building targeting lists)
Security Tools Reference
| Tool | Purpose | URL | |---|---|---| | Revoke.cash | Audit and revoke token approvals | revoke.cash | | Etherscan Token Approvals | Alternative approval checker | etherscan.io/tokenapprovalchecker | | Pocket Universe | Pre-simulation Chrome extension | pocketuniverse.app | | Wallet Guard | Malicious site detection | walletguard.app | | NFTnerds.ai | Wash trading and manipulation detection | nftnerds.ai | | Etherscan Contract Verify | Check if contract source is verified | etherscan.io (green checkmark) | | Certificate Transparency | Find all domains using a project's TLS cert | crt.sh | | OpenSea Verified Collections | Cross-reference collection contract address | opensea.io/collection/[name] |
The NFT security landscape has improved materially since 2022. Wallet Guard and Pocket Universe catch most signature-based attacks. Rabby Wallet's pre-simulation blocks the majority of setApprovalForAll exploits. Hardware wallet clear signing makes it possible to verify Seaport orders before signing them. MetaMask has added its own transaction simulation layer.
What has not changed: the attacker's fundamental approach still works. A victim who bypasses every warning, clicks through every yellow screen, and signs anyway will lose their assets. Social engineering does not need technical vulnerabilities — it needs a moment of inattention, urgency, or trust. The defense is education about what exactly each signature does, not the tools themselves.