CASE-006: Deanonymisation of a Telegram Extortion Ring

The Counterparty Who Wasn’t There

A prominent CIS-region fintech platform’s SOC paged its head of security at 02:14 on a Sunday. Layer-7 distributed denial-of-service traffic was hitting the primary payment gateways at a rate the upstream provider could absorb but the application layer could not. Customer-facing transaction success rates dropped from baseline to near zero across a fifteen-minute window. The platform’s incident-response runbook activated. The CDN added a rule. The traffic shifted shape and continued. The CEO’s personal Telegram, at 02:41, received a message from a bot. The message demanded a substantial Bitcoin payment to halt the attacks and threatened to release what it described as a stolen KYC database inside seventy-two hours. The CEO forwarded the message to the head of security, the general counsel, and to us under an existing retainer.

The instruction was a single sentence: definitively attribute the attacks inside seventy-two hours, in a form that local law enforcement could act on, and determine whether the alleged database was real. Payment was off the table. The platform’s customer-facing communications team needed a defensible position on the database threat within the same window; an external attribution of the source as a bluff would change the public-relations posture. An attribution of the source as real would mean immediate customer notifications and a different incident response.

“The DDoS was containable. The database threat was the question that decided whether we’d be telling our customers anything by Tuesday morning. We needed an external attribution we could put weight on.”
— Head of security, CIS-region fintech platform

What the Registries Said

The work combined our standard Telegram deanonymisation playbook with cryptocurrency-flow tracing on the Bitcoin wallet address the bot had disclosed. The operators had practised reasonable OPSEC. They communicated through Tor exit nodes. The bot’s first-tier handlers contained no exploitable artefacts. The bot’s getMe response had been deliberately stripped of identifying fields and the bot’s public profile carried a stock-library image. The payment-instruction message was administrative, neutral, and gave nothing away. Reasonable OPSEC is, in our experience, what operators of this profile present at the front of the engagement; the seam is almost always somewhere in the operational history of the infrastructure that the operator has forgotten to clean up.

The first systematic pass enumerated the bot’s creation, edit and webhook history through the standard Telegram OSINT enumeration techniques and through the archival engines that record Telegram entity metadata across time. The bot exposed its first artefact through a historical webhook record. Three months before the attack window, the bot had briefly been bound to a webhook on a small VPS in an autonomous system long-documented in published abuse-tracking reports for ignoring abuse complaints. The webhook had been active for forty-eight hours and then changed; the historical binding was preserved in the relevant Telegram metadata snapshots and was recoverable through standard enumeration.

“Operators who are careful about today are almost never careful about a webhook they set up three months ago when they were still iterating on the infrastructure. That’s the seam, every time.”
— Senior deanonymisation analyst, [0x]INT

Cross-reference of the TLS certificate active on that IP during the forty-eight-hour webhook window, via crt.sh and the standard Certificate Transparency log indices, surfaced a then-dormant domain whose WHOIS record had been redacted at the registrar level but whose passive-DNS history, recorded by a public DNS-archive project, showed a two-hour period of DNS pointing at a residential ISP block in a specific Russian regional centre during initial domain setup. The two-hour pointing was old — almost two years earlier than the attack window — but it was preserved in the passive-DNS archive and it was the structural fingerprint of an operator who had set up the eventual command-and-control domain from home before later carefully concealing it behind privacy services and bulletproof hosting. The residential ISP block was a single /24 in the specific regional centre. The operator’s home connection had touched the apex once, briefly, in a moment of carelessness, and the trace had survived.

The Layer Underneath the Layer

The on-chain leg corroborated. The Bitcoin wallet the extortionists had provided was operationally sterile until a small test transaction moved a sub-percent amount to a deposit cluster at a designated Russian exchange under OFAC, EU and UK sanctions. The exchange’s deposit cluster routed onward, through a small handful of intermediate addresses, to a deposit address at a small OTC desk in a downtown Moscow business district whose physical operating window we cross-referenced against the bot’s posting cadence over the preceding three weeks. The OTC desk’s typical operating hours, lunch closure, and end-of-day window matched a corresponding gap in the bot’s posting cadence across the entire observable history of the channel to the minute. The operator was, on the most parsimonious reading of the behavioural data, a single principal coordinating attacks remotely from a residence in one Russian regional centre while physically commuting on weekdays to a Moscow OTC desk for cash-out activity. The DDoS infrastructure was real and externally sourced. The extortion infrastructure was a single person.

The “stolen” KYC database was, as a parallel workstream confirmed, a bluff. The bot had offered, as a “sample,” a small CSV that purported to contain user profile fields. On inspection against the platform’s own public-facing user profile pages — the platform exposed certain profile fields on its public site for any registered user who had opted in — the CSV was a reformatted scrape, not a database extraction. Every record in the sample mapped, field for field, to a publicly-visible profile. None of the fields the platform held in its internal KYC store but did not expose publicly — identity-document numbers, dates of birth, AML risk scores — appeared in the sample. The sample was, technically, a competent scrape; it was not a breach. The threat was a bluff dressed in the language of breach.

“The ‘sample’ was their own public site, scraped and reformatted. Once we’d shown the customer-facing team that, they knew exactly what to say. And what not to say.”
— General counsel, CIS-region fintech platform

Where the Money Touched Ground

Inside seventy-two hours we delivered a full intelligence dossier identifying the residential-infrastructure origin, the cash-out pattern, the OTC desk attribution, the on-chain hop chain, and the bluff status of the alleged database. The dossier was structured to be defensible in a subsequent criminal proceeding under the relevant CIS-jurisdiction computer-misuse and extortion statutes and to support the platform’s decision to make no payment and to maintain a customer-facing posture of confidence in the integrity of its KYC store.

The dossier was passed by the client to competent local authorities under the relevant statutory mechanism. The DDoS halted within hours of a law-enforcement arrest at the residential address identified by the passive-DNS pivot. The Telegram bot ceased posting. No extortion payment was made. The platform’s customer-facing communications team was able to maintain a posture of confidence in the integrity of the KYC store on the basis of the parallel workstream’s conclusion that the alleged sample was a public-page scrape. The platform’s external-perimeter monitoring was subsequently extended to include the Certificate Transparency and passive-DNS pivots that surfaced the operator’s hosting history in this matter; the same pivot pattern has, on retrospective analysis, surfaced two further operator-attribution candidates against unrelated infrastructure in the months since.

“Seventy-two hours, no payment, a customer-comms posture we could defend, and an arrest at the address. That is what an end-to-end attribution looks like when the operator gives you one historical webhook to work with.”
— Head of security, CIS-region fintech platform

What We Took Away

Three patterns from this engagement that have generalised across our subsequent Telegram-extortion attribution work, particularly against operators combining DDoS, Telegram-bot extortion, and on-chain payment instructions.

Historical webhook records are the most under-used pivot in Telegram-bot attribution. Operators who run a bot for any length of time will, over its operational lifetime, bind and re-bind the webhook against different upstream infrastructure as they iterate. Each binding generates metadata that is preserved across time and recoverable through standard enumeration. An operator who is careful about the current binding will, in our experience, have been careless about a binding from three months earlier. The discipline is to enumerate the full historical webhook chain, not the current state. Our public Telegram OSINT playbook documents the enumeration workflow.

The Certificate Transparency log is the most under-used pivot in domain-attribution work generally. Operators who switch to a privacy-protecting registrar after initial setup, or who route their public-facing infrastructure behind a CDN, almost universally assume that the registrar privacy and the CDN front have erased the prior public footprint. They have not. crt.sh mirrors the RFC 6962 logs across multiple operators. Every TLS certificate the operator has ever requested for any sub-domain of their apex is permanently public. The historical issuance record, cross-referenced against passive-DNS archives, is the structural backbone of the modern domain-attribution workflow. Our cryptocurrency tracing playbook covers the complementary on-chain workflow.

Behavioural-cadence overlap is the most defensible single attribution heuristic. A bot whose posting-cadence gaps mirror, to the minute and across multiple weeks, the operating-hour pattern of a specific physical location is, in attribution terms, a strong inference. The inference becomes nearly decisive when the same physical location is independently corroborated by the on-chain leg of the cash-out chain. The discipline is to capture the cadence histogram before the engagement narrative starts and to capture the OTC desk’s operating-hour pattern as a separate workstream rather than as a confirmation of an existing hypothesis. The independence of the two workstreams is what makes the convergence defensible.

External public-record sources referenced in this methodology

• crt.sh — Certificate Transparency search interface.
• IETF RFC 6962 — Certificate Transparency standard.
• Telegram Bot API documentation — getMe, getWebhookInfo.
• US Treasury OFAC press-release archive — Russia-related crypto exchange designations.
• OpenSanctions — cryptocurrency-address sanctions index.
• Blockchain.com Bitcoin block explorer.
• ENISA — Threat Landscape and DDoS-trends publications.
• FIRST.org — international incident-response and forensics standards organisation.

About this engagement

Case identifiers, the client’s name and specific CIS-region jurisdiction, the specific bulletproof-hosting autonomous system, the specific Russian regional centre identified by the passive-DNS pivot, the specific Moscow OTC desk attribution, and the named local-law-enforcement mechanism have all been adjusted to protect client confidentiality and to avoid prejudicing the criminal proceeding the dossier supported. The methodology, the role of historical Telegram-bot webhook bindings and Certificate Transparency in surfacing pre-privacy infrastructure, the behavioural-cadence overlap between bot posting and OTC operating hours, and the public-page-scrape attribution for the alleged stolen database are accurate to the engagement.