Someone @'d Me at 3:42 PM — What the Second Message Told Me About the First

You finished Monday morning’s impersonation report, wrote “48-hour observation period” in your tracker, and moved on. At 3:42 PM someone in the same Telegram group @‘d you again.

Illustrative group message (composite material, not a real community message):

User C [15:42] @security another account added me. Username is project_official_claim, link goes to claim-project[.]net. Different domain from this morning.

User D [15:50] I got it too. Same script — says check airdrop eligibility.

Six hours. Same group, a similar username pattern, a variant domain. The account you had taken down that morning was only the first wave.

If you had closed the case after the first report, this message would have started everything from zero — ask the group who else received it, check the domain, file another report, wait. By the time you finished, the attacker could be on a third script. Because you kept a tracker, you knew exactly what to compare.

What you logged that morning

Go back to 9:23 AM Monday. User A @‘d you in the official group saying someone direct-messaged them about “checking airdrop eligibility.” The username was project_official (the official handle is projectofficial), and the link pointed to claim-project[.]com.

Before reporting the account, you did a few things:

• Saved screenshots with timestamps and usernames. One of the group message, one of the DM screen — material for comparing script changes later.
• Checked when the impersonator joined the group. The Telegram group admin panel showed it joined at 3:12 AM that day, and the account was registered the day before. Not a long-dormant account — one created specifically to wait for group access.
• Asked User A and User B whether they still had the full DM thread. User B had already deleted the contact, but at least confirmed the script said “connect your wallet to verify airdrop eligibility.”
• Logged the known domain. claim-project[.]com. Registration date unknown at that point.

The report went through at 11:45 AM and the account was banned. You wrote one entry in your tracker and marked it 🟡 Yellow.

Case ID: BR-2025-0414-01

• Discovered: 04-14 09:23
• Accounts closed: 1
• Known domain: claim-project[.]com
• Known DMs sent to: at least 2 people
• Response level: 🟡 Yellow (impersonator banned, 48-hour observation period)
• To verify: whether other accounts from the same batch exist; domain registration details

Yellow does not mean “all clear.” It means you do not have to drop everything today, but you must check again tomorrow.

Six hours later, three signals changed the color

When User C’s message came in at 3:42 PM, you checked your tracker against three things.

First: the username changed. This morning it was project_official (impersonating the official handle). This afternoon it was project_official_claim — same impersonation pattern, different naming scheme.

Second: the domain changed. From .com to .net. A variant domain — the attacker registered multiple TLDs under the same base name.

Third: the timing. The first account was banned at 11:45 AM. The new one appeared at 3:42 PM — under four hours later. That suggests an operational process, not someone trying once on a whim. Someone checked the account status and activated a backup.

You moved the response level from 🟡 Yellow to 🟠 Orange.

The core task at Orange is not “report it again.” It is collecting structural information to estimate how deep the attacker prepared.

Three things to check — not urgent, but necessary

First: domain registration dates. Run whois on both domains (all figures below are illustrative):

• claim-project[.]com: registered 2025-04-10, registrar NameCheap
• claim-project[.]net: registered 2025-04-10, registrar NameCheap

Same day, same registrar. The attacker started preparing domains at least four days before the incident was discovered. Search claim-project[.]org and .io under the same registrar too — registered but unused domains also go into the log.

Second: recent group join records. Go to the Telegram group admin panel and check accounts that joined in the last week. You find three accounts that joined between 04-10 and 04-12, all registered within the same window — silent, no avatar, usernames in an “alphanumeric” pattern. They could be backup accounts, or they could be regular users — you cannot be certain. But the timing overlap with the domain registration dates is worth noting. Save the user IDs. Do not ban them — banning tells the attacker you are investigating, and new accounts entering fresh will be harder to spot.

Third: script variation. Users said the afternoon script was the same. The attacker had not changed the lure yet, which means they were still running pre-written bulk messages and had not received enough failed responses to iterate.

After those three checks, you confirmed this was a prepared multi-domain, multi-account attack. But you needed one more piece of information before deciding whether to go to Red.

The screenshot that came in at 10 PM

Illustrative group message (composite material, not a real community message):

User E [22:18] An account this afternoon said the official site had a new UI and asked me to approve a test. I didn’t look at the domain carefully and clicked it. 0.5 ETH was taken from my wallet. Screenshot: [image]

User F [22:30] I got that new-UI message too but didn’t click. The account doesn’t look like the same one that sent the airdrop script.

The script had changed. The attacker switched lures in the evening — from “check airdrop” to “new UI test” — which means they saw the airdrop script was not converting well enough during the day and adjusted. And User E’s screenshot showed that the new script had already caused actual asset loss.

You escalated again: 🟠 Orange → 🔴 Red.

At Red level, the tracker tracks three things

The goal at Red is stopping further damage and preserving evidence, not “catching the attacker.” That is beyond what a community security operator can do and beyond their authorization boundary.

What you can do:

• Post a confirmation announcement in the group — list the confirmed fake domains (claim-project[.]com and .net), state the official domain clearly, and inform members that victims have been identified. Keep the tone factual.
• DM the users you previously logged as having been contacted, reminding them not to click any links. Do not @everyone in the public group.
• Preserve the evidence chain: report records, whois results, group message screenshots, victim screenshots — filed by time and source.

What you do not do:

• Do not post a bounty in the group asking for hacker intel.
• Do not promise “we will recover the assets” — you cannot control on-chain fund flow. Victims should contact their wallet provider or exchange directly.
• Do not publish the attacker’s Telegram ID. A public ID serves no real purpose and can be exploited by copycats.

Your tracker now reads:

Case ID: BR-2025-0414-01

• Confirmed impersonator accounts: 3 (1 banned in the morning, 1 reported in the afternoon, 1 dormant account pending verification)
• Confirmed phishing domains: at least 2 (.com + .net)
• Known victims: at least 1, loss of 0.5 ETH (illustrative figure for demonstration only, does not represent a real incident)
• Response level changes: 🟡 09:23 → 🟠 15:42 → 🔴 22:18
• To verify: whether the two remaining variant domains are registered and active; the victim’s wallet type and the authorized contract address; whether group access should be temporarily switched to invitation-only

Next time someone reports, you have a baseline

Back to the starting question: after you report a fake account, when can you feel safe?

Not when the account is banned. Not when nobody in the group reports another one. You feel safe when you have confirmed that the attacker’s batch of domains and backup accounts have been exhausted and the new entry points are closed.

You cannot know how many usernames the attacker registered. But you can estimate their preparation cycle and operational rhythm from three threads: domain registration dates, account-join batches, and script-change timing. If you had not left that yellow tracker entry after the first wave, the afternoon message would have started you at zero. By the time you worked through the流程, the attacker could be on a fourth script.

A tracker does not need many fields. Three lines of notes, one color code, one item under “to verify.” Enough that when you open it, you know the current level and what to check next.

The next time someone @‘s you, you will not ask “is it happening again?” You will pull up the previous table, compare the pattern, the domain, and the script, and decide — escalate or close.

PRODUCT SCOPE

Market and risk discussion is supporting evidence

Top Prospect is primarily a Telegram lead-generation product. Market and risk discussion can add context to a candidate lead, but it does not become a verified incident, trend, or sales opportunity automatically.

Review the product workflow and boundaries →