Breaches Weekly, 1–7 Nov 2026: 186.5M Claimed Telegram Scrape Rows and The Tour Guy

Also this week: Ransomware Weekly, 1–7 Nov 2026: claimed Henry Pratt, Atomberg and Kirkland & Ellis files.

Covers leaks indexed by HaveIBeenRansom between 2026-11-01 00:00 and 2026-11-07 23:59 UTC. Each case shows when it was posted and when its data became searchable. How we pick cases, read records and score attribution: methodology.

Why these two

A file advertised as scraped Telegram messages and a dataset labelled The Tour Guy became searchable in HaveIBeenRansom during 1–7 Nov 2026. The first is notable for 186,545,050 indexed records and the claimed combination of messages with account identifiers. The second contains 3,695,691 indexed records and a concentration of travel-booking relay domains. Both deserve attention as potential sources of convincing impersonation; neither establishes a new compromise of the named service this week.

We propose these two cases as exceptions to the usual same-week posting requirement. The Telegram post was observed on 30 October and The Tour Guy copy on 11 October, while indexation falls on 3 and 2 November respectively. The exception for Telegram rests on scale and the claimed message-to-identity linkage. The exception for The Tour Guy rests on the travel context, over a million email-bearing records and separate October reporting of a claimed release. First-ever circulation is not independently established for either exact copy. This edition therefore covers newly searchable material, not two newly confirmed incidents.

We selected two cases whose limitations we can explain concretely, without adding a third solely to fill the format. Unrelated Telegram-labelled files remain separate populations.

Swipe horizontally to read every column. Selected files indexed 1–7 Nov 2026. Posting dates and indexing dates are shown separately. Counts are records, not people.

Key findings

The source dates below are HIBR discovery/post-observation dates, not verified first publication or intrusion dates. The Telegram offering describes scraping; it is not evidence that Telegram's systems were breached. Contents attributed to the postings or outside reporting remain claims. This edition uses metadata rather than raw personal records. Its email statistics describe record occurrences, not a deduplicated contact list; the two datasets have not been compared for overlap.

1 · Telegram (posted by F1bases)

HIBR entry: Telegram on HaveIBeenRansom

What happened. F1bases advertised a Telegram message scrape in a post observed on 30 October, according to the description retained by HIBR. The posting says it collected messages across chats; the associated file became searchable on 3 November. This is an account of a data-trading post about scraped content, not a report that Telegram's infrastructure or private-message encryption failed. The posting date is an observation of this copy, not proof that none of the material circulated before it.

Scale. HIBR indexes 186,545,050 records. The posting claims 187,905,245 records, a difference of 1,360,195. No evidence identifies the reason for that gap: it cannot be assigned to deduplication, missing messages or parsing losses without further information. The posting also claims 6,442 chats. That chat count has not been independently checked, and neither it nor the record total establishes a unique-user count.

What the data contains. The retained post lists identifiers, usernames, display names, phones, message IDs, dates, text and media-type fields. These are the advertiser's description, not fields confirmed by inspecting personal records. HIBR's format metadata identifies CSV material and additional document, email, mailbox, PDF and text counters, which are non-additive. Only 159,455 indexed records carry an email observation, or 0.09% of the total. That makes email a narrow view of a file advertised primarily around messages and account identifiers. It does not tell us how many valid phones or complete conversations are present.

Corporate vs Personal. The email-bearing subset is split 55.04% corporate-classified and 44.96% personal-provider. The classifier places ukr.net in the corporate bucket, so the grouping does not verify an employer relationship. In a message scrape, an address can be mentioned in conversation without belonging to the author. None of the listed domain owners is identified as compromised on this basis.

Mixed message content; domains may be mentions. Corporate classification is not an employer or victim finding. Source: HIBR entry.

Corporate-classified: 87,763 (55.04%); personal-provider: 71,692 (44.96%). Denominator: 159,455 email-bearing records, not deduplicated people or mailboxes. Corporate means the API's non-personal-provider bucket, not employees or ownership. Each table uses its own bucket as denominator.

Attribution confidence: 33/100 (low). The API reports 33/100 after inferring telegram.org as the target organisation. That organisation-attribution model is a poor fit for a scrape spanning many conversations. Analyst assessment: the offered material is likely message-oriented scraped content, with low confidence, supported by the posting description and metadata but without authentication of the records. The score provides no probability of a Telegram breach. Verifying the collection method and dataset provenance would strengthen this judgement.

Why it stands out this week. The volume and claimed combination of text with identifiers are the grounds for the proposed date exception. If authentic, that context can make impersonation more convincing without requiring access to an account. Investigators need to establish which statements and identifiers are linked. The total does not establish that 186.5 million different people were breached. The selection does not establish that the material was first released in 2026.

2 · The Tour Guy (posted by Formaceft DB)

HIBR entry: The Tour Guy on HaveIBeenRansom

What happened. HIBR records a copy labelled The Tour Guy in the Formaceft DB channel on 11 October, then indexes it on 2 November. In a separate 12 October report, SOCRadar describes an actor advertising The Tour Guy data and alleging an August 2026 incident. That corroborates circulation of a claim in October; it does not establish that the report and this indexed file refer to identical data or that the underlying incident is confirmed.

Scale. This entry contains 3,695,691 indexed records, including 1,322,214 email-bearing records, or 35.78%. SOCRadar reports the actor's separate claim of more than 3.8 million records. The populations have not been reconciled, so the numbers are not interchangeable and no missing-record count is inferred. Neither figure establishes the number of customers, bookings or valid contact addresses.

What the data contains. HIBR classifies the indexed material as four CSV source files. Its aggregate metadata supports the record and email counts, not the detailed sensitivity of each row. SOCRadar relays claims involving identity, contact, authentication and payment information; those categories remain unverified for this copy. No conclusion is drawn that usable passwords, session tokens or full payment-card data are present. An advertised sensitive field warrants investigation, but it does not prove that the data can be used.

Corporate vs Personal. The leading corporate-classified domains are expmessaging.tripadvisor.com at 43.07% and reply.getyourguide.com at 21.70%. The labels are consistent with booking-message relays, so a count under them should not be treated as a staff population. A file-like anomaly, www.projectexpedition.com.com, also appears in the output and is preserved as reported rather than silently corrected. These observations cannot show that Tripadvisor, GetYourGuide or Project Expedition was an intrusion point or suffered its own breach. Investigators need to establish how a contact value relates to a booking or communication; the size of a platform's bar does not answer that question.

Booking relay domains and parser artefacts; counts do not identify unique travellers or compromised platforms. Source: HIBR entry.

Corporate-classified: 685,094 (51.81%); personal-provider: 637,120 (48.19%). Denominator: 1,322,214 email-bearing records, not deduplicated people or mailboxes. Corporate means the API's non-personal-provider bucket, not employees or ownership. Each table uses its own bucket as denominator.

Attribution confidence: 18/100 (low). The API's 18/100 uses ten raw points out of 55 evaluated and applies a third-party concentration penalty. Its inferred organisation-domain list also contains an archive-name artefact, which limits the score's meaning. Analyst assessment: a travel-related data origin is likely, with moderate confidence, from the relay-domain pattern and independent observation of an October claim. Attribution of this exact copy to The Tour Guy remains low confidence. A provenance match between the indexed files and independently verified organisational data would strengthen that narrower link.

Why it stands out this week. The proposed exception rests on scale, the sizeable email-bearing subset and the specific travel context available to an impersonator, together with October reporting of a claimed release. It is not a finding of a new November attack. For travellers, the practical concern is a convincing request tied to an apparent trip; for providers, it is correctly distinguishing booking relays from personal accounts before taking action.

What they have in common

• Both cases separate posting in October from indexation in November. The dates establish this week's search availability in HIBR, not the freshness of every underlying record.
• Both contain mixed email domains. A company domain in a message or travel booking does not make that company a victim, an employer of the person concerned, or the attack vector.
• Both offer potentially believable context for impersonation: claimed message history in one case and travel-related contact patterns in the other. Exact authenticity and current account access remain unresolved.

What defenders can do

Telegram users and community moderators should treat quoted conversation details as weak proof of identity. If someone invokes a chat, username or message history to request money, access or a verification code, confirm through a previously established route. Review phone-number visibility, active sessions and account verification settings in the app. These are precautionary steps for the advertised scraping scenario, not an assertion that sessions or private messages were stolen.

Travellers should verify booking changes in the service they already use. For an unexpected payment, refund or identity-document request, open the existing booking directly or contact the operator through a known route. A message that contains travel context or a relay address still requires verification. Do not send documents or payment details in response to an unsolicited claim that a booking has a security problem.

Fraud and trust-and-safety teams should preserve the distinction between relay addresses and personal mailboxes. Match a suspicious interaction against authorised internal booking records, with access restricted to the people investigating it. Do not label every platform in the domain table as compromised or convert the indexed record total into an affected-customer estimate.

Security teams should act on evidence of valid access rather than the seller's field list. If internal checks substantiate exposed credentials or sessions, revoke the affected access and investigate related activity. The joint CISA guide provides relevant guidance on access controls and response. Neither the advertised password fields nor these aggregate statistics demonstrate that a current account can be accessed.

---

Is your email or phone number in one of these leaks? Check it for free · Get an alert if it shows up in a new leak

DarkEye Threat Research · Data: HaveIBeenRansom · Indexing methodology peer-reviewed in MDPI Electronics · Attribution confidence is a heuristic estimate (method v2.0), not a formal attribution.

← Previous edition · All Breaches Weekly editions