When a Project's Own Channel Posts the Scam
A compromised community account is the most effective phishing delivery available, because the trust is already established.
Priya Raman · 2 min read
The most convincing phishing message is the one posted by the project itself, in its own channel, by an account with an administrator badge.
This happens regularly.
How the channel gets compromised
A moderator account is phished. The most common route. Moderators are identifiable, numerous, and not always security-conscious.
A bot token leaks. Community management bots hold permissions to post and sometimes to change permissions. A leaked token grants both.
A malicious bot is added. Someone with permission adds an integration that turns out to be hostile.
Session token theft. Malware on a moderator’s machine steals an authentication token, which bypasses two-factor entirely because the session is already authenticated.
That last one defeats good password hygiene and is worth knowing about specifically.
What the compromised channel does
Announces an unexpected mint, an airdrop claim, a migration, or an urgent security measure requiring users to connect a wallet.
Then frequently locks the channel so nobody can post a warning, and deletes messages from users who noticed.
The lock is the tell. A legitimate announcement does not require silencing the community.
Why users fall for it
Every heuristic points the right way. Correct channel, verified account, administrator badge, consistent tone, and other members reacting positively, some of whom are the attacker’s own accounts.
There is no external signal that anything is wrong.
The defences
Never act on urgency from any channel. A genuine announcement survives you checking it elsewhere in an hour. Legitimate projects do not create deadlines measured in minutes.
Cross-check on a second channel. A compromise of one channel is common; simultaneous compromise of the project’s site, its social accounts and its documentation is rare.
Navigate to claim pages yourself. Type the project’s domain and find the announcement there, rather than following a link.
Treat migration announcements as hostile by default. Almost every real migration is handled by contracts without users needing to move funds, and “migrate your tokens” is one of the most common scam formats.
Use a separate wallet for claiming anything. Structural rather than behavioural, which is why it works.
For project operators
Reduce the number of accounts with posting permission. Require hardware keys for all of them. Audit bot integrations and their permissions. Have an out-of-band announcement channel that is harder to compromise and that users know to check.
And publish a policy stating that the project will never ask users to connect a wallet in response to an urgent announcement, so that the policy itself becomes a check users can apply.
The general rule
The reliability of a message is not established by where it appears. Channels are compromised routinely.
What can be verified independently is the destination. Type the domain, check the contract address against the documentation, and keep the connecting wallet small enough that being wrong is survivable. For anything involving money you cannot afford to lose, the venue holding it, such as platforms with a real complaints process, is reachable by no announcement in any channel.
Move any remaining funds to a wallet with a newly generated seed phrase before anything else. Then revoke token approvals, and report the incident to your local authorities and the exchange involved. Do not pay anyone who promises to "recover" your coins. That is a second scam, aimed at victims of the first.