CASE-002: Telegram Ghost — Operator Identified in 72h

The Counterparty Who Wasn’t There

The chief operating officer of a privately-held industrial group with operations across two Russian federal districts woke at 04:40 to a Telegram notification forwarded from his head of security. A channel called something innocuous — the kind of name a regional logistics consultancy might use — had opened a fortnight earlier with no followers, no posts, and a stock-library cover image. Overnight it had posted nine documents in rapid succession. Internal procurement records. Board-meeting minutes from the previous quarter. Three personal emails between the COO and the group’s general director that should not have existed outside two specific corporate mailboxes. The last post was a short paragraph in flat administrative Russian setting out a Bitcoin address, an amount, and a deadline of seventy-two hours, after which “remaining material” would be released. The channel had four hundred followers by 06:00. By the time the client’s general counsel called us, the documents had begun to circulate in copy on three regional business-news Telegram channels.

The client’s internal IT team had spent the night looking for evidence of network intrusion and had found nothing. No anomalous logins. No unusual data transfers. No malware indicators. The leak appeared to originate from somebody who already had legitimate access. The general counsel needed two answers and he needed them inside the seventy-two-hour clock: who was operating the channel, and was there an ongoing internal source still exfiltrating material in real time. Payment was not on the table. Quiet attribution to a form a Russian district court could act on was.

“Our SIEM was clean. Our endpoint logs were clean. Whoever did this had keys we’d given them. We just didn’t know which set.”
— Head of information security, industrial group (CIS region)

What the Registries Said

Telegram looks anonymous and is not. The platform exposes considerable structural metadata to any patient enumeration: channel creation dates derived from message-id arithmetic, posting-cadence histograms, message-edit timestamps, forwarded-from attributions that survive even when the source channel has since been deleted, and a quiet inventory of which other channels an account has interacted with publicly. The first day of work was a systematic pass across the channel’s complete published history at that point — thirteen posts — capturing every accessible artefact and structuring it into a timeline.

The operator had taken obvious precautions. The channel had been created from a session that exposed no SIM information in any public-facing artefact. Posting cadence was clustered between 09:00 and 19:00 Central European Time rather than Moscow time — the kind of detail a careful operator deliberately offsets to mislead behavioural localisation. No media files in the channel retained recoverable EXIF. The profile image had been lifted, by reverse-image search, from a generic stock library a decade old. The contact channel for “negotiations” was a Telegram bot, not a direct username, and the bot’s info response had been deliberately stripped of identifying fields. On the surface, this was a careful operator.

“The first eleven posts told us nothing about the operator. They told us a great deal about how the operator wanted us to read him. That’s also signal.”
— Senior OSINT analyst, [0x]INT

We worked the bot side in parallel with the channel side. The bot’s payment-instruction message contained an external link to a static-content mirror site for a “public list of demands” that the bot intended to publish if payment was not received. The mirror site was hosted at a small VPS provider in a Western European jurisdiction. Certificate Transparency logs for the bot’s mirror domain disclosed not just the current certificate but a prior issuance on a personal sub-domain of the same apex, dating from sixteen months before the channel went live. The prior sub-domain had been issued for a small personal git-server instance, and the WHOIS record, before the operator had switched to a privacy-protected registrar, had carried an email address at a major free-mail provider. That email address was the operator’s first failure.

The Layer Underneath the Layer

Post twelve was the second failure, and the structurally interesting one. The post was a screenshot of an email exchange between the COO and the group’s general director, captured from one of the two executive mailboxes. The screenshot was a clean PNG. EXIF was stripped. No window-chrome timestamp was visible. But the email-client interface visible in the screenshot rendered the recipient’s display-name preference in a configuration uncommon enough that, against the small pool of individuals with legitimate access to the mailbox, it materially narrowed the suspect set. The render configuration was, in plain reading, the personal preference of a specific person who had configured the mailbox client a particular way at a particular time. The operator had screenshotted from his own copy of the mail, not from a forwarded forensic capture.

From the email address recovered through the certificate-transparency pivot, we ran username re-use enumeration across two large code-forge platforms and against a series of public breach-data corpora reachable through the standard public-domain searchable indices. The handle returned a small portfolio of personal repositories on one of the forges. The git commit metadata on those repositories exposed both a real name (the operator had committed under his actual name in the early commits before later switching to a privacy alias) and a time-zone offset that matched the channel’s posting cadence to the minute. The name was a known name to the client. The individual was a former contractor whose project had wrapped four months earlier.

“Every operator forgets one thing. With this one, the thing he forgot was a git commit from 2018 with his real name on it. Eight years of careful OPSEC undone by a teenage open-source project.”
— Senior OSINT analyst, [0x]INT

Cross-reference of the contractor against the client’s internal-source pool returned a single match. His access had not been revoked when his project completed. His retained credentials still permitted read on the document store from which the leaked material had been taken. Three weeks before the channel went live, he had created — from inside his still-active corporate mailbox — an auto-forwarder routing all incoming mail to a personal address under his control. The auto-forwarder’s creation timestamp lined up against the document-exfiltration pattern visible in the leak: every document in the channel’s first thirteen posts had been touched by his mailbox or the document store within the auto-forward window. The shape of the engagement was no longer attribution. It was off-boarding hygiene.

Where the Money Touched Ground

Inside seventy-two hours we delivered a deanonymisation report naming the contractor, with a documented citation chain for each pivot: the certificate-transparency record, the recovered email address, the username re-use trail, the git-commit metadata, the time-zone correlation against the channel’s posting cadence, and the corporate auto-forwarder record from the client’s own mail-server logs. The report was structured to be defensible in a subsequent criminal proceeding under the relevant CIS-jurisdiction computer-misuse statute and to support an immediate civil application for an interim injunction against republication.

The client revoked the contractor’s access immediately, preserved the corporate-mail audit trail under a forensic protocol, and the matter was referred to counsel for criminal complaint under the relevant CIS-jurisdiction statute. The Telegram channel ceased posting within forty-eight hours of access revocation. No extortion payment was made. The follow-on engagement was an off-boarding-procedure review: the access-revocation gap that allowed retained credentials to remain valid for four months after project end is now closed by an automated revocation hook tied to the contractor-management system.

“We had a defensible attribution we could put in front of a prosecutor and a remediation we could put in front of our board. Both inside the same week.”
— General counsel, industrial group (CIS region)

What We Took Away

Three patterns from this Telegram Ghost engagement that have generalised across our subsequent Telegram-deanonymisation work, where a careful operator runs ghost infrastructure that nonetheless leaves a public trail.

Certificate Transparency is the single most under-used pivot in Telegram operator work. Operators who run their own infrastructure — mirror sites, payment-page hosts, support-bot webhooks — routinely fail to anticipate that every TLS certificate they have ever issued for their domain is permanently logged, publicly searchable, and immune to post-hoc registrar privacy. crt.sh is free, the underlying RFC 6962 logs are mirrored across multiple operators, and a single grep against the apex domain will surface every sub-domain the operator has ever certificated. For the operator who is currently running a careful privacy posture but who two years ago ran a personal homepage on the same apex, the historical issuance is the entry point.

The screenshot of an internal artefact is almost always a self-incriminating object. Operators who leak documents often screenshot from their own working environment rather than reformatting through a clean intermediary. The screenshot will contain timestamp configurations, language-pack indicators, font-rendering preferences, client-application identifiers, and occasionally the operator’s own cursor position. None of these is individually identifying. The combination, against a small pool of suspects with legitimate access, frequently is. We document a fuller version of the Telegram-side discipline in our Telegram OSINT playbook and in the deanonymisation-service brief at /services/deanonymization/.

Off-boarding is the persistent control failure. The single most reliable predictor of an internal-leak engagement, across our case portfolio, is a delayed credential revocation against a departed contractor or employee. Modern corporate environments grant credentials liberally and revoke them slowly. The four-month gap in this engagement is, on our experience, slightly below the median. A periodic privileged-access audit against the contractor-management system is the cheapest single control that materially reduces this exposure class. For organisations whose contractor base is large or whose document store is sensitive, the audit cadence should be quarterly at a minimum and the revocation hook should be automated rather than manual.

External public-record sources referenced in this methodology

• crt.sh — Certificate Transparency search interface (Sectigo, mirrors RFC 6962 logs).
• IETF RFC 6962 — Certificate Transparency standard.
• Google Certificate Transparency Report — aggregate CT log statistics and lookup.
• Telegram Bot API documentation — webhook and getMe metadata fields.
• Telegram OSINT community tooling indexes (GitHub awesome-lists).
• FIRST.org — international incident response and forensics standards organisation.
• ENISA — European Union Agency for Cybersecurity guidance on incident handling.
• OCCRP Aleph — investigative archive of leaked corporate documents and breached datasets.

About this engagement

Case identifiers, the client’s sector and jurisdiction, the specific timeline of the extortion-channel posting cadence, and all individually identifying details of the named contractor have been adjusted to protect client confidentiality. The methodology, the role of Certificate Transparency in surfacing pre-privacy WHOIS history, the screenshot-fingerprinting pivot, and the off-boarding hygiene lesson are accurate to the engagement. No published claim in this case study identifies a real natural person, real corporate entity, or real Telegram channel.