Author: Mark Kyle
Category: Threat Intelligence / OSINT
Reading time: 7 min

Summary

In November 2025, our team observed a broker on a public Telegram channel advertising VPN access to a large manufacturing company. The seller, who used the handle “Apex_Vault” (a pseudonym), claimed to hold working credentials, session tokens, and network diagrams.

Using passive OSINT only, we built a profile of the actor’s infrastructure and produced leads about who may be behind it. This write-up covers the methods, what each pivot did and did not prove, and where our confidence is low. We are not publishing any individual’s identity. We assess the attribution below as low-to-moderate confidence, and the findings were [reported to [agency/CERT] on 3 Nov 2025. The victim was notified on 14 Aug 2025, and the access was [confirmed remediated on 18 Feb 2025.

Scope and ethics

• All collection was passive. We did not contact the actor, purchase access, or log in to any victim system.
• We did not use stolen credentials to access any third-party accounts. When moving from passive OSINT intelligence gathering to active legal proceedings, regulatory notifications, or formal case reports, verifying the acquisition protocol of breach and stealer data with legal counsel is a non-negotiable step.
• The victim has been anonymized, and indicators are defanged or redacted where publishing them would aid the actor or harm bystanders.

Step 1: The advertisement

The initial indicator was a public post offering SSL-VPN access plus session tokens for a named company, priced in Monero, with proof available by direct message.

Pivot on stable identifiers. Handles change; account IDs generally don’t. We recorded the account’s numeric Telegram user ID and the channel’s message metadata so we could track the actor if the handle changed. We also searched the handle across code-hosting sites, forums, and username-enumeration tools, which returned no direct matches.

Step 2: Infrastructure

The actor hosted “proof” screenshots on a self-registered domain, which we’ll call cdn-example[.]com.

• Registration: registered in August 2025, three months before the advert, through a budget registrar.
• Passive DNS and certificate transparency: historical records showed the domain once resolving to the same IP address as two subdomains of a second domain, example-sec[.]net, including hostnames suggesting dev and VPN-gateway use.

Caveat: Verifying the network footprint of 185.220.101[.]42 reveals critical context that changes how an investigator should handle that specific pivot: Shared hosting, VPN, or Tor exit ranges produce false overlaps all the time, and a shared IP alone shows co-hosting, not common ownership. We treated this link as a lead, not a conclusion.

Step 3: Historical WHOIS and breach-data correlation

Before privacy protection was applied, historical WHOIS for the second domain listed a registrant email on a privacy-focused mail provider.

We then checked that email against commercial infostealer-exposure and breach-index services. The email appeared in a stealer log from early 2025. The log metadata indicated a Windows host, a country-level IP geolocation, and installed software associated with networking and reverse-engineering work.

What this does and does not show:

• It shows that the email address was present on an infected machine.
• It does not show that the machine’s owner operated the Telegram account. Stealer logs can include unrelated accounts, shared machines, and recycled data.
• It does not establish that the infection was self-inflicted, as an earlier draft suggested. That was speculation, and we have removed it.

Step 4: Weighing the leads

We assessed three links:

• Telegram handle → proof domain
  • Evidence: the actor posted the domain’s image links themselves
  • Confidence: high
  • Weakness: none significant
• Proof domain → second domain
  • Evidence: shared historical IP
  • Confidence: low
  • Weakness: possible co-hosting only
• Second domain → email → stealer log
  • Evidence: historical WHOIS and log metadata
  • Confidence: low to medium
  • Weakness: registrant data can be fabricated, stale, or reused

Beyond this point, any link to a named real-world person depended on weak identifiers: similar first names, a code-hosting commit email, and facial-similarity search results. We did not treat these as verification, and we are not publishing them. Facial-similarity tools return candidates, not identifications, and they are particularly error-prone across common names and transliterations.

1. Pivot on stable identifiers, not handles.
2. Record the confidence level of every link, and write down what would falsify it.
3. Keep the attribution at the level the evidence supports, and hand identity questions to law enforcement.

Alternative explanations we couldn’t rule out:

• The registrant details belong to someone else (a reseller, a prior owner of the infrastructure, or a deliberately planted identity).
• The advertiser is a front for a larger group.
• The stealer-log entry is unrelated to the person who registered the domain.

Our assessment: the infrastructure is consistent with a single operator based in [region, only if the evidence supports this], at low-to-moderate confidence. We make no claim about any individual’s identity.

Detection and mitigation takeaways

For defenders:

1. Monitor broker channels for your company name and domains. Early warning gave us time to alert the victim.
2. Enforce phishing-resistant MFA on remote access and shorten VPN session-token lifetimes. Session theft bypasses passwords.
3. Alert on anomalous VPN sessions (new device, geography, or impossible travel) and rotate credentials when a listing appears.
4. Treat stealer-log exposure as an incident, because it shows endpoint compromise, not just a password leak.

For investigators:

Indicators

*TTP Summary (MITRE ATT&CK Matrix)
-T1566.002 (Phishing: Spearphishing Link): Distribution via Telegram illicit sales channels.
-T1005 (Data from Local System): Theft of localized VPN profile keys and browser storage.
-T1584.004 (Compromise Infrastructure: Server): Utilization of generic cloud storage subdomains for staging access proof.
-T1589.002 (Gather Victim Identity Information: Email Addresses): Git metadata exposure during code commits.