5. The Fraud Catalog I

The first frauds were impersonation. Before the smart contracts, before the AI, before any of the machinery the rest of this book will spend its chapters dismantling, the foundational move was simply this: wear a trusted face. Find a room where people have already decided whom to believe, then become that person. Everything else — the drainer contracts, the synthetic communities, the voice clones — is elaboration on a single primitive that has not changed since the first con artist put on a uniform he had no right to wear.

It is worth slowing down on why this works so well in an open community, because the mechanism is not psychological in the way the anti-fraud pamphlets imply. It is structural. In a closed environment — a corporate Slack, a family group chat — identity is anchored by something outside the chat. You know your coworker because HR hired them and you've sat across a desk from them. You know your sister because she's your sister. The name on the message is a label for a person you already have an independent relationship with. In an open community, that anchor is gone. The thousand strangers in a crypto project's announcement channel have no out-of-band relationship with the admin. They know "the admin" entirely through artifacts the platform presents: a display name, an avatar, a position in a member list, a colored tag. Trust attaches to those artifacts, not to a person. And artifacts can be copied.

That is the entire vulnerability, stated once so we don't have to restate it for every scam in this catalog. When trust attaches to a copyable artifact rather than to a verified person, impersonation is not a clever exploit. It is the default behavior of a rational attacker. Every fraud in this chapter is, at bottom, the same lie told with different props: I am someone you have a reason to trust, and I am not. Hold onto that. We are going to watch it recur until it stops looking like a collection of separate scams and starts looking like one problem wearing many costumes.

A note on how to read this catalog and the one that follows: I sort frauds the way a defender sorts them — by mechanism, not by victim story — because the mechanism is what you can build against, and because it reveals the shared root the stories conceal. This chapter holds the fast ones: high volume, low touch, monetizing in minutes on impulse, panic, or greed, each attempt costing the attacker almost nothing to mount. Keep one running tally as you read — at every step, ask what it cost the attacker to look like someone they are not. The answer, with grim consistency, will be: almost nothing.

The dominant vector: admin and moderator impersonation

If you spend any time reading incident reports from crypto and trading communities, one pattern dominates the others so thoroughly that defenders treat it as the baseline. It is the impersonation of admins and moderators. Not because it is sophisticated — it is the least sophisticated attack in this book — but because it is the highest-leverage application of the copyable-artifact problem, and because the venue hands the attacker most of the tools for free.

The anatomy is worth laying out precisely, because every defense that fails against it fails for the same reason. An open project has a public group. The group has admins, who are visibly marked: a tag, a pinned welcome message naming them, a position near the top of the member list. New members arrive constantly — that's the point of a growth-oriented community — and they arrive without any prior knowledge of who the real admins are. They learn it on the spot, from the artifacts. So the attacker manufactures the artifacts. They set their display name to match an admin's exactly, or near-exactly with a homoglyph swap — a Cyrillic "а" for a Latin "a," a capital "I" for a lowercase "l," a zero-width character padding the string so the two names are visually identical but programmatically distinct. They copy the admin's avatar, which is a public image anyone can download. On platforms where users can set a "bio" or status, they copy that too. In under five minutes, with no technical skill, they have produced a profile that is, to a human reading a phone screen, indistinguishable from a person the room has already agreed to trust.

Then comes the maneuver that defeats the in-chat moderation stack entirely: the fraud does not happen in the chat. The impersonator stays clean in public. They post nothing, or they post something anodyne. What they do instead is open a direct message. A new member asks an innocent question in the group — "how do I stake?", "is the presale live?", "my transaction is stuck" — and within seconds receives a DM from someone whose name and picture match the admin they just saw answer someone else. The DM is helpful, patient, and fluent in the project's jargon. It walks the victim to a website, a "verification" step, a wallet connection, a seed-phrase entry. By the time anything visibly bad happens, the conversation has left the moderated room and is happening in a private channel that no moderation bot, no admin, and no shared banlist can see.

This is the detail that matters for the argument of this book, so I'll state it flatly. The entire moderation toolset built up over a decade — the keyword filters, the anti-flood limits, the CAPTCHAs at the gate, the shared banlists — operates on the public room. The impersonation attack uses the public room only as a directory. It reads the room to learn whom to imitate and whom to target, then conducts the actual fraud in a venue the defenses do not cover. You can run a flawlessly moderated group and lose members to admins who never broke a single rule inside it, because they did all their work one click away in a DM.

Consider what a defender can actually do about this, because the inventory of available countermeasures is short and every item on it is a confession. The standard advice — and it is good advice, as far as it goes — is to pin a warning: admins will never DM you first. Communities post it, bots repeat it, the genuine admins say it aloud. And it helps, at the margin, with the most credulous victims. But notice what that advice is. It is an admission that the platform cannot tell a real admin from a fake one, so the burden of identity verification is pushed onto the least-equipped party in the transaction — a new member, on a phone, who joined ninety seconds ago and does not yet know the norms. It is security by folklore. The second countermeasure is to forbid DMs from non-contacts at the account level, which works but defeats the social purpose of an open community, where serendipitous contact is half the value. The third is a class of bots that watch for new accounts whose display names collide with known admins' and flag or ban them — and this is the best of the bunch, but it is a perpetual cat-and-mouse against a free resource, because the attacker simply registers a new account with a slightly different homoglyph and tries again. Every one of these countermeasures shares a property: it treats the symptom in the room while the disease — that a name is not bound to a person — sits untouched in the identity layer.

There is a darker variant of the impersonation attack that does not bother to imitate at all, and it is worth naming because it shows the ceiling of what impersonation becomes when an attacker invests slightly more. Instead of cloning an admin's profile, the attacker compromises the real one. A phished or malware-infected admin account is worth far more than a convincing fake, because it carries no homoglyph tell, no "this account was created yesterday" signal, no mismatch a vigilant member could catch. It is, by every artifact the platform exposes, the genuine article — because it is. That is how the $1.35 million Thor theft from the prologue began: not with a clone but with a hacked friend's real account. Note it here because it marks the boundary condition of this whole chapter: the perfect impersonation is not a copy of a trusted identity. It is the trusted identity itself, stolen. And no amount of "check the name carefully" defeats it, because there is nothing wrong with the name.

Telegram is where this pattern reached its purest expression, and it's worth being honest about why, because the reasons generalize. The platform combined the largest concentration of high-value crypto communities with a set of design choices that, individually defensible, compounded into an impersonator's ideal habitat: display names that are freely chosen and freely duplicated, the ability to message many users who haven't explicitly opted in, usernames that look authoritative, and — critically — no native, portable signal of who an account actually is. But none of this is unique to one app. The same attack runs on Discord, where impersonators copy a server's moderator role color and username and DM new joiners — Discord's own trust-and-safety guidance has for years carried the same folkloric warning, "a staff member will never DM you first." It runs on X, where blue checks and matching handles get cloned to impersonate project founders in replies. The constant across all three is the constant of this book: open access, plus value in the room, plus an identity layer too weak to bind a name to a person.

It's worth pausing on the homoglyph and lookalike techniques specifically, because they're the part most people underestimate, and because they explain why automated matching is harder than it sounds. The naive version of name-collision detection compares the impersonator's display name to the admin's as strings: if they're identical, flag it. But Unicode contains thousands of characters that render nearly or exactly identically while being entirely different code points — the Latin "a," the Cyrillic "а," and the Greek alpha can all look the same in many fonts, and that's before you reach the deliberately confusable glyphs, the combining marks, and the invisible zero-width characters that can be sprinkled into a name to change its byte sequence without changing its appearance at all. An attacker can produce a name that is, to the human eye, a perfect match for the admin, while being, to a string comparison, a completely different value. Defenders responded with normalization — collapsing confusables to a canonical form before comparing — and attackers responded by attacking the normalization, finding glyphs the normalizer missed or appearance-collisions it didn't model. This is a microcosm of the whole war this book describes: a defense that operates on the representation of identity rather than on identity itself can always be evaded by manipulating the representation, because the representation has more degrees of freedom than any matcher can fully cover. The only thing that would end the homoglyph game is binding the account to a verified identity, so that the name is merely a label and the trust lives somewhere uncopyable. That is the identity lie again — the same one beneath every entry in this catalog — and I am going to stop flagging it now. By the end of the next chapter you will see it without my pointing.

A specific and especially cruel refinement deserves naming, because it shows how the impersonator reads the room's social structure, not just its roster. In trading and investing communities, the highest-trust figure is often not the admin but the recognized "helper" — a long-tenured member, not on staff, who answers questions for free and has accumulated genuine social capital. Impersonating that person is in some ways more dangerous than impersonating an admin, because the room's veterans will vouch for the name reflexively. "Oh, talk to [helper], they're solid." The attacker harvests that reflex. They clone the helper, wait for the vouch, and convert borrowed reputation into a drained wallet. The vendor tools we'll look at in Chapter 17 have given names to subspecies of this — the "Trust Builder," the "Multi-Account Wave" — and we'll evaluate whether the naming amounts to a defense. For now, note only the shape: the attacker is not exploiting a bug in the software. They are exploiting the fact that reputation in these rooms is attached to a name, and the name is free.

Fake support bots: impersonation, automated

The next item in the catalog takes the impersonation primitive and removes the human from the attacker's side of it. Instead of a person pretending to be an admin, a bot pretends to be official support — and because it's a bot, it scales the way software scales, which is to say without limit.

The mechanism preys on a specific moment of vulnerability: the moment a user has already lost crypto, or fears they have, and is looking for help. A trade fails. A wallet looks drained. A transaction hangs. The user does the natural thing — they search the platform for the project's support channel, or they type a distress message into a community and wait. Both behaviors are harvestable. Attackers stand up bots with names like "Wallet Support," "TON Support," "MetaMask Helpdesk" — names engineered to surface in search and to look official in a results list. Some monitor public channels for distress keywords and DM the user proactively, arriving at the exact instant the victim is most motivated and least skeptical. The bot then runs a script with one real objective: extract the credentials that grant control of the victim's assets — the seed phrase, the private key, the session token, the wallet connection approval. There is no support. There was never any support. The entire apparatus exists to be a sieve for secrets, dressed as a lifeline.

The script is a decision tree dressed as a conversation. It greets the victim warmly, expresses concern, and funnels relentlessly toward the one thing it needs, with branches for every hesitation: reassurance ("this is a standard security step"), authority ("I'm a verified support agent"), urgency ("your funds are at risk — we need to act now"). What the victim experiences as an attentive human is a finite state machine with a single accepting state: secret captured. Because it is software, it never tires, never breaks character, and can run ten thousand of these conversations in parallel, each one feeling, to its target, like undivided personal attention — the asymmetry the AI era will later tear wide open. The economics are the part worth sitting with: once the script is written, talking to the ten-thousandth victim costs the operator nothing, while the defender pays human or compute attention to inspect every interaction. Defense by inspection against an adversary with zero marginal cost is a losing race by construction.

The bot variant is also more insidious than the impersonated admin in one respect: discovery. The impersonated admin has to be in the room. The fake support bot is found by the victim, through search, scooping up marks from projects whose communities it has never entered — pre-positioned to surface for distress queries the way a black-hat SEO operator games a search engine. The victim walks into the trap entirely on their own. And this is impersonation of an institution rather than a person — "official support" as a category — which is harder to second-guess because there is no specific real admin to compare against, only the diffuse expectation that a big project must have a support desk somewhere. The platform cannot contradict the claim, because it has no notion of "the official support account for this project" that it can authenticate; "official" is an artifact, and artifacts copy. So the bots run, and when one is reported and removed, the operator loses nothing of consequence: the script is saved, the harvesting back end untouched, and the next bot costs a few minutes and a fresh account — free, as everything in this catalog is free. Removal is not a deterrent when the thing removed was disposable by design.

Fake airdrops and giveaways: weaponizing the free lunch

The airdrop is a genuine and common mechanism in crypto communities — a project distributes free tokens to early users, holders, or participants, as marketing or as a reward. Because the real thing exists and is broadly understood as "free money for doing something small," it makes a perfect template for fraud. The victim's expectation has been pre-installed by the legitimate ecosystem; the attacker only has to satisfy it with a counterfeit.

What makes the airdrop such fertile ground is that the legitimate version trains the exact behavior the fraudulent version needs. A real airdrop asks users to connect a wallet, sign a message proving ownership, and sometimes complete a small on-chain action — and it does so on a website they reached through a link in a community channel. Every one of those steps is also a step in the scam. The fraud doesn't have to teach the victim anything new or talk them into anything unusual; it has to convince them that this particular instance of an entirely routine procedure is the real one. The cognitive load is minimal precisely because the legitimate ecosystem has normalized the dangerous behavior. This is a recurring tragedy in crypto's security story: the same composability and permissionless design that make the technology powerful also mean that the safe action and the catastrophic action are often indistinguishable to the user at the moment of decision. Connecting your wallet to claim a real airdrop and connecting it to a drainer look identical until the consequences diverge, and by then the signature is on-chain and final.

The fake airdrop comes in a few standard configurations, and they sort neatly by what they're actually stealing. The crudest steals attention and account access: "Claim your $TOKEN airdrop — connect your wallet to verify eligibility," leading to a site that requests a wallet connection and a signature. The victim believes they are proving they own a wallet in order to receive a gift. What they are actually signing, in many cases, is a transaction or an approval that hands spending authority over their tokens to the attacker — which brings us to drainers, the subject of the next section, because the fake airdrop is very often just the bait on a drainer hook. A second configuration steals crypto directly through the "gas fee" or "activation fee" trick: the airdrop is real-looking, the tokens appear to be "reserved" for you, but to "release" them you must first send a small amount of crypto to cover a fee. You send it. Nothing releases. The fee was the entire transaction. A third configuration, common on Telegram specifically, dresses the whole thing as an official platform event — a "TON Giveaway," a "Wallet" promotion — using the names and visual language of the platform's own products to borrow institutional credibility. Fake clones of Fragment, the official TON username and number marketplace, have circulated for exactly this reason: a convincing clone of a known-official site inherits the trust the user already extends to the original.

The urgency dressing is consistent across all three and worth a sentence, because it's the lever that converts a skeptical user into a fast one. Real airdrops are sometimes time-boxed, so the fake ones imitate the time box and crank it: the claim window closes in two hours, only the first five thousand wallets qualify, the eligibility snapshot is tonight. Scarcity and deadline are not incidental decoration; they are the mechanism by which the attacker prevents the victim from doing the one thing that would save them, which is to stop and check. A victim who has time to ask in the real channel "is this airdrop legit?" usually gets told no. So the fraud is engineered to deny them the time. This, too, is a pattern you'll see escalate later — the manufactured deadline is a primitive that survives every era, because it attacks the victim's decision process rather than their knowledge, and the decision process is the same whether the bait is a fake airdrop in 2021 or an AI-driven investment pitch in 2026.

The delivery vector for fake airdrops is, predictably, impersonation again — the channel pretends to be the project's announcement channel, or the DM pretends to be from an admin sharing "early access," or the giveaway bot pretends to be official. There is a recursive quality to this catalog that I want you to start noticing: the airdrop scam is delivered by an impersonated admin, who points you to a phishing site, which runs a drainer. These are not four separate scams. They are four stations on one assembly line, and the assembly line's first station is always the same — a false identity that gets the victim to lower their guard. The downstream stations only get to run because the lie at the top of the funnel succeeded.

Phishing: the link is not the point

Phishing in these communities follows the patterns the broader security world knows well — a deceptive message drives the victim to a site that harvests something — but two adaptations are worth pulling out, because they're specific to the open-community, crypto-adjacent environment and because they preview the drainer mechanics that close this chapter.

The first adaptation is the collapse of the gap between phish and theft. In classical phishing, the fake site harvests a password, and the attacker then has to log in somewhere to monetize it — there's a step between the catch and the cash. In wallet phishing, that gap can vanish. A crypto wallet's authority is exercised by signing transactions, and a malicious site can present a signing request directly. If the victim approves it, the theft is the signature; there is no separate "log in and steal" step, and frequently no way to reverse it. This is why crypto-targeted phishing is more dangerous than the credit-card variety the public is inoculated against: there is no chargeback, no fraud department, no issuer to call. Finality is a feature of the technology and a gift to the attacker.

The second adaptation is the rise of the fake-CAPTCHA and fake-verification pattern, which has become a workhorse in trading channels. A user clicks a link — from an impersonated admin, naturally — and lands on a page that presents what looks like a routine human-verification step: a CAPTCHA, a "verify you're not a bot," a "connect to continue." The page is theater. Its actual function is to get the victim to perform an action — paste a command, approve a connection, install an extension, or hand over a session token — that grants the attacker access. One especially nasty subspecies, sometimes called the "ClickFix" or "paste-and-run" lure, instructs the victim to copy a snippet of text and paste it into a system dialog or a console to "complete verification" — and what they are actually pasting is a command that downloads and runs malware on their own machine, with their own hands. The genius of the fake CAPTCHA is that it exploits a habit the entire internet has trained into us: verification steps are friction to be clicked through as fast as possible, not security boundaries to be scrutinized. The victim's own muscle memory does the attacker's work. In trading communities specifically, this pattern has been used to harvest the session tokens that authenticate a user to a trading bot or exchange — and a stolen session token is often as good as the password and the second factor combined, because it represents an already-authenticated state. The token is the proof of who you are, and once it's copied, the attacker is you, for as long as the session lives.

There is a structural point hiding in that last sentence that reframes phishing as something other than a content problem. A session token, a private key, a seed phrase — these are all, fundamentally, identity claims: the secrets that let a system answer the question "who is this?" with "this is the legitimate owner." Phishing, stripped to its essence, is the theft of identity claims through a false identity — the attacker pretends to be someone trustworthy in order to capture the secret that lets them pretend to be you to a machine. The platforms cannot stop this at the message layer not because their filters are bad but because the thing being stolen and the thing being faked live in the same place, the layer these platforms decline to anchor. Strip away the impersonated sender and the phishing site is a stranger shouting "give me your keys" — a proposition that converts at a rate near zero. The technical payload is interchangeable.

Wallet drainers: theft as a service

We arrive at the payload that monetizes a large share of the frauds above, and at a fact worth registering even though its full story belongs to Chapter 7: the people writing the malicious smart contracts are mostly not the people running the scams. The impersonators, the fake-airdrop runners, and the phishers of this chapter deliver victims to draining infrastructure that someone else builds, operates, and rents out. What stands behind the drain page — the vendors, the affiliate programs, the commission splits — is the subject of Chapter 7. Here, stay on the victim's side of the screen.

Mechanically, a drainer is a piece of front-end code paired with a set of smart-contract interactions, designed to convert a single careless wallet approval into the largest possible extraction. The sophistication is in the maximization. A naive thief might get the victim to approve a transfer of one token. A modern drainer scans the connected wallet, identifies the most valuable assets, and crafts the signing request to capture as much as the victim's approval allows — sometimes a blanket token-spending approval that the drainer then exercises at leisure, sometimes a single bundled transaction that sweeps multiple assets at once. Many lean on approval primitives that are perfectly legitimate parts of the token standards — the kind of "allowance" mechanism that lets a decentralized exchange move your tokens on your behalf — and simply point that legitimate machinery at the attacker's address. The victim sees a signing prompt that, on the small screen of a phone, is nearly illegible — a wall of hex and contract addresses — and they have been primed by the impersonated admin and the fake airdrop to click "approve." They click. The wallet empties. The cruelest detail is that nothing about the final transaction is technically malformed or exploitative in the way a buffer overflow is. The victim authorized it. The blockchain did exactly what it was told. The fraud happened entirely upstream, in the social layer, where the victim was convinced that the hand reaching for their assets belonged to a friend.

There is a venue-specific refinement worth a moment, because it shows the drainer pattern adapting to a platform's own primitives rather than fighting them. On TON, the blockchain integrated into Telegram, attackers have built fake "TON Giveaway" and "Wallet Support" Mini Apps — applications running inside the chat client itself — that solicit malicious approvals through TON Connect, the platform's native, legitimate wallet-connection flow. The victim never leaves the trusted client, which strips away one of the few remaining instinctive warning signs. And that connection flow authenticates a wallet keypair, not a person — a distinction that looks small in the documentation and will turn out, when this book reaches its endgame, to be enormous.

The frauds in this chapter share one more property, and it sets up the next chapter: they are fast. The impersonated admin wants the seed phrase now; the fake support bot wants the session token now; the drainer wants the signature now. They are high-volume, low-touch, and they convert on impulse and panic — the smash-and-grab end of the economy. But there is another half to the catalog, and it operates on the opposite principle. It is patient. It builds a relationship over weeks before it asks for anything, and when it finally asks, the victim hands over not a single wallet but a life's savings, willingly, believing the whole time that they are talking to a friend, a lover, an investment mentor. The identity lie does not get smaller in those frauds. It gets deeper, and it gets far more expensive. That is where we turn next.