In July 2026, RESIDENT.NGO investigated a Telegram phishing message sent to a Belarusian activist living in Lithuania. The link led to a fake Telegram page that asked for a login code. The link also contained the target’s phone number in encoded form. After examining that site, we searched for other pages built and operated in the same way.
We found a wider cluster visible in public and commercial telemetry from at least October 2024 through July 2026. Google Threat Intelligence (GTI) records contained 64 distinct phone numbers embedded in individualized links across seven domains: 55 Russian, 7 Belarusian and 2 Kazakhstani numbers. These numbers are likely intended targets, but the records alone cannot prove that every link was delivered or that any account was compromised.
Four newer domains shared exact application code and distinctive response behavior. Two older domains appear to be an earlier generation of the same framework. A seventh domain is strongly connected by naming, timing and infrastructure, although its phishing code was not captured for direct comparison.
GTI recorded 70 submission events associated with these individualized links. In 50 cases, the apparent submission country matched the country of the embedded phone number.
Plain-language summary: the investigation began with one phishing attempt and led to a longer-running, multi-country infrastructure cluster. The evidence links the websites and hosting, but does not identify a specific operator.
1. Scope and methodology
This report expands the technical case study of tgcheckprotect[.]com into a campaign-level infrastructure analysis. It uses the artifacts collected during the original incident together with GTI/VirusTotal URL, domain and submission records; Censys and Shodan observations; IPinfo network records; RDAP registration data; and certificate information contained in the supplied datasets.
Data cutoff and interpretation. The dataset was collected through 22 July 2026. GTI first-submission timestamps show when a URL entered the dataset, not necessarily when it was sent to a target. GTI submission geography reflects the apparent network location of the submitting source and may represent a recipient, researcher, security product, mail gateway or VPN exit.
We use three confidence categories:
- Code-confirmed: exact application-level script hashes and distinctive behavior were captured across the domains.
- Closely related predecessor: the same URL design, page structure, response headers and bailout behavior were observed, but the exact newer script hashes were not captured.
- Operationally related: the domain is linked by naming, timing, registration, nameservers, infrastructure and individualized URLs, but a directly comparable phishing payload was not preserved.
2. The related domain cluster
The seven domains fall into three evidence tiers. This classification describes the strength of the technical link; it does not claim that every deployment was controlled by the same person or team.
| Assessment | Domain | Basis |
|---|---|---|
| Code-confirmed | tgconfirm-repair[.]com | Exact shared scripts, headers, personalized URLs and response behavior |
| Code-confirmed | tgsafeprotect[.]com | Exact shared scripts, headers, personalized URLs and response behavior |
| Code-confirmed | tgauth-confirm[.]com | Exact shared scripts; shared origin and certificate relationship with tgconfirm-repair[.]com |
| Code-confirmed | tgcheckprotect[.]com | Exact shared scripts and behavior; domain used in the original RESIDENT.NGO case |
| Closely related predecessor | tg-confirm[.]com | Earlier page generation using the same URL deception, phone token and bailout logic |
| Closely related predecessor | tg-repair[.]com | Earlier page generation using the same URL deception, phone token and bailout logic |
| Operationally related | tgreviewcheck[.]com | Same naming pattern, individualized links, registration timing and nameserver pairing; payload not captured for code comparison |
Five of the seven domains were registered through PDR Ltd. d/b/a PublicDomainRegistry.com, while two were registered through Realtime Register B.V. The registrations form two particularly close provisioning groups: tgsafeprotect[.]com and tgconfirm-repair[.]com were registered six days apart through Realtime Register, while tgauth-confirm[.]com and tgreviewcheck[.]com were registered through PDR on the same day, less than two hours apart. Registrar reuse supports the infrastructure clustering when combined with code, nameserver, certificate and hosting evidence, but does not by itself establish common ownership. The existing report already identifies these February and June provisioning clusters.
| Domain | Registration date | Registrar | IANA registrar ID | First GTI observation |
| tg-confirm[.]com | 21 February 2024 | PDR Ltd. d/b/a PublicDomainRegistry.com | 303 | 22 October 2024 |
| tg-repair[.]com | 3 October 2024 | PDR Ltd. d/b/a PublicDomainRegistry.com | 303 | 6 January 2025 |
| tgsafeprotect[.]com | 5 February 2026 | Realtime Register B.V. | 839 | 5 February 2026 |
| tgconfirm-repair[.]com | 11 February 2026 | Realtime Register B.V. | 839 | 11 February 2026 |
| tgauth-confirm[.]com | 2 June 2026 | PDR Ltd. d/b/a PublicDomainRegistry.com | 303 | 3 June 2026 |
| tgreviewcheck[.]com | 2 June 2026 | PDR Ltd. d/b/a PublicDomainRegistry.com | 303 | 4 June 2026 |
| tgcheckprotect[.]com | 24 June 2026 | PDR Ltd. d/b/a PublicDomainRegistry.com | 303 | 6 July 2026 |
tg-confirm[.]com was originally registered through PDR on 21 February 2024 and was used during the observed campaign period. After that activity, the domain appears to have expired or changed hands and was re-registered through NameSilo on 10 June 2026. The later registration should not be treated as part of the phishing infrastructure described here. Current registration and DNS records can reflect later re-registration, parking or repurposing
2.1 Exact code links in the newer generation
GTI captures for tgconfirm-repair[.]com, tgsafeprotect[.]com, tgauth-confirm[.]com and tgcheckprotect[.]com contained the same distinctive JavaScript hashes. The captures also shared the Telegram Web title and metadata, similarly sized phishing pages, the userID cookie holding the encoded phone token, the country_code cookie in some visits, and the same client-hint response headers.
| Captured component | SHA-256 |
|---|---|
| mainform | 1a473d1d3e2610608c8b331389434f6a138d6738a015cdff6ca7171270755652 |
| check / i18n / border | 370d02139f4f2d777c260d55a008e3bc28971b7e9fecc35ccfba77a5f26fe8bc |
| lottie / bodymovin | c8a4c8fcc633dfc0be94438b38f8e38ada81b5994b0cb79d0275ed5f05314869 |
2.2 Earlier and incompletely captured deployments
The tg-confirm[.]com and tg-repair[.]com captures used an earlier page generation. They shared the deceptive telegram[.]org@domain URL structure, Base64-encoded phone parameter, Telegram-themed pages, distinctive client-hint headers and the redirect to telegram[.]org/faq. Their successful page sizes clustered around 3,696-3,699 bytes and later 4,200 bytes. Because the exact newer script hashes were not preserved, they are described as closely related predecessors rather than byte-identical deployments.
For tgreviewcheck[.]com, GTI preserved individualized links and several operational connections, but the successful phishing payload was not captured for code comparison. It is therefore kept outside the code-confirmed set.
3. How the framework worked
The individualized lure URLs followed a repeated structure:
hxxps://telegram[.]org@<phishing-domain>/?<Base64(phone number)>
Everything before the @ symbol is treated by the browser as user information. The actual destination is the phishing domain after the @. The query value decodes to a phone number, which the server can display on the fake Telegram page. A syntactically valid numeric token, combined with an eligible browser and platform profile, could receive the phishing interface; other configurations were shown decoy content, an error page or a redirect to Telegram.
The same framework family also exposed a phone-entry page at /login on at least one origin. This suggests that the infrastructure could support both operator-generated individualized URLs and a more conventional first step in which a visitor enters a phone number. The available records do not reveal the backend panel or prove successful account takeover.
4. Targeting visible in individualized URLs
Across the seven domains, GTI records contained 64 distinct phone numbers embedded in individualized URLs. Russia accounted for 55 numbers (85.9%), Belarus for 7 (10.9%) and Kazakhstan for 2 (3.1%).
| Domain | Distinct numbers | Russia | Belarus | Kazakhstan | First GTI observation | Last GTI observation |
|---|---|---|---|---|---|---|
| tg-confirm[.]com | 12 | 12 | 0 | 0 | 22 Oct 2024 | 08 Feb 2026 |
| tg-repair[.]com | 12 | 8 | 3 | 1 | 06 Jan 2025 | 15 Dec 2025 |
| tgsafeprotect[.]com | 4 | 4 | 0 | 0 | 05 Feb 2026 | 08 May 2026 |
| tgconfirm-repair[.]com | 20 | 20 | 0 | 0 | 11 Feb 2026 | 25 May 2026 |
| tgauth-confirm[.]com | 4 | 2 | 1 | 1 | 03 Jun 2026 | 18 Jul 2026 |
| tgreviewcheck[.]com | 5 | 5 | 0 | 0 | 04 Jun 2026 | 19 Jun 2026 |
| tgcheckprotect[.]com | 7 | 4 | 3 | 0 | 06 Jul 2026 | 22 Jul 2026 |
What this establishes. The repeated appearance of Belarusian and Kazakhstani numbers across different domain generations shows that the activity was not limited to Russia.
5. Apparent GTI submission geography
The 64 distinct numbers were represented by 70 GTI submission events associated with 67 anonymized source keys. Most submissions appeared to come from Russia. Belarus and Kazakhstan were smaller but showed a strong relationship between the embedded phone-number country and the apparent source country.
| Apparent submission country | Submission events | Distinct source keys |
|---|---|---|
| Russia | 43 | 42 |
| Belarus | 6 | 6 |
| Netherlands | 5 | 4 |
| Germany | 3 | 3 |
| Kazakhstan | 2 | 2 |
| Czechia | 2 | 2 |
| United States | 2 | 2 |
| Poland | 2 | 2 |
| Lithuania | 2 | 1 |
| Austria | 1 | 1 |
| Unknown | 1 | 1 |
| Estonia | 1 | 1 |
Overall, 50 of 70 events (71.4%) came from the same country as the embedded number. Among web-interface submissions, 49 of 66 (74.2%) were country-aligned. Both Kazakhstan-number links were submitted from Kazakhstan. Five of seven Belarus-number links were submitted from Belarus. Forty-three of 61 Russia-target submission events appeared to come from Russia.
Interpretation limit. A GTI submission location is not automatically a victim location. A recipient may use a VPN, travel, forward a link to another country, or submit it through a security service. The data is best used as supporting evidence for regional targeting, not as proof of where a particular person lived or where the operator was based.
6. Timeline of observed activity
The domain sequence shows overlapping deployments rather than a simple one-for-one replacement. Older and newer domains were visible at the same time, and several pairs were provisioned close together.
| Period | Domains | Observed development |
|---|---|---|
| Oct 2024 | tg-confirm[.]com | First individualized URL in the dataset; Russian number. |
| Jan-Jul 2025 | tg-repair[.]com | Expanded to Russian, Kazakhstani and Belarusian numbers. |
| Dec 2025-Feb 2026 | tg-confirm[.]com and tg-repair[.]com | Older generation remained active; submission volume increased in December. |
| Feb-May 2026 | tgsafeprotect[.]com and tgconfirm-repair[.]com | Newer code-confirmed generation operated in parallel; 24 distinct Russian numbers across the two domains. |
| Jun 2026 | tgauth-confirm[.]com and tgreviewcheck[.]com | Paired new domains; Kazakhstan, Russia and Belarus appeared on tgauth-confirm[.]com. |
| Jul 2026 | tgcheckprotect[.]com | Four Russian and three Belarusian numbers; domain used in the original RESIDENT.NGO investigation. |
6.1 Provisioning clusters
- February 2026: tgsafeprotect[.]com was registered on 5 February and tgconfirm-repair[.]com on 11 February, both through Realtime Register.
- 2 June 2026: tgauth-confirm[.]com and tgreviewcheck[.]com were registered through PDR less than two hours apart.
- Shared nameservers: tgconfirm-repair[.]com and tgauth-confirm[.]com used damiete.ns.cloudflare[.]com and veda.ns.cloudflare[.]com. tgcheckprotect[.]com and tgreviewcheck[.]com used sreeni.ns.cloudflare[.]com and tony.ns.cloudflare[.]com.
- Shared deployment: tgconfirm-repair[.]com and tgauth-confirm[.]com resolved to 80[.]76[.]42[.]201 and were covered by the same certificate deployment observed in the supplied data.
These overlaps strengthen the technical association between the domains, but registrar or nameserver reuse alone is not evidence of common ownership.
7. Origin and hosting infrastructure
The origin analysis separates attacker-controlled or campaign-associated servers from redirect destinations and CDN edges. The addresses 104[.]21[.]26[.]210 and 172[.]67[.]168[.]142 are Cloudflare edge addresses, while 149[.]154[.]167[.]99 is Telegram infrastructure reached after redirects. They are not treated as phishing origins.
| Domain | Candidate origin | Assessment | Basis / limitation |
|---|---|---|---|
| tg-confirm[.]com | 45[.]151[.]139[.]85 | Strong probable historical origin | Earlier generation; current domain records reflect later re-registration or parking and are excluded from campaign attribution. |
| tg-repair[.]com | 45[.]151[.]139[.]84 | Probable historical origin | Same 45.151.139.0/24 hosting block as other historical candidates. |
| tgsafeprotect[.]com | 93[.]170[.]123[.]163 | Confirmed historical origin | Exact-domain certificate and successful framework responses. |
| tgconfirm-repair[.]com | 80[.]76[.]42[.]201 | Confirmed shared deployment | Direct DNS and certificate evidence; shared with tgauth-confirm[.]com. |
| tgconfirm-repair[.]com | 80[.]76[.]42[.]108 | Strong probable historical origin | Successful GTI pages and same /24 hosting environment as 80[.]76[.]42[.]201. |
| tgconfirm-repair[.]com | 45[.]151[.]139[.]85 | Strong historical association | Observed in historical host records; later repurposed. |
| tgauth-confirm[.]com | 80[.]76[.]42[.]201 | Confirmed origin | Shared deployment with tgconfirm-repair[.]com. |
| tgreviewcheck[.]com | 45[.]151[.]139[.]71 | Probable historical origin | Domain association preserved, but no comparable successful phishing page. |
| tgcheckprotect[.]com | 45[.]130[.]151[.]58 | Confirmed origin | Direct A record, exact-domain certificate and live phishing content. |
All seven domain-associated candidate origins fall within the Time-Host/VPSville hosting ecosystem or closely associated address space identified in the supplied records. This concentration is useful for campaign mapping, but it does not prove that the same hosting customer controlled every server.
Geolocation data for these addresses was not uniform. Several origins were consistently mapped to Moscow, Russia, while others produced conflicting results across Censys, Shodan and IPinfo. These differences may reflect routing changes, address reassignment or inaccuracies in commercial geolocation databases. They should not be treated as proof of a server’s physical location.
| IP address | Associated domain or role | Geolocation recorded in the supplied data |
|---|---|---|
45[.]130[.]151[.]58 | tgcheckprotect[.]com | Moscow, Russia |
45[.]151[.]139[.]71 | Probable tgreviewcheck[.]com origin | Moscow, Russia in Censys; Almaty, Kazakhstan in Shodan |
45[.]151[.]139[.]84 | Probable tg-repair[.]com origin | Moscow, Russia in Censys; Almaty, Kazakhstan in Shodan |
45[.]151[.]139[.]85 | Historical association with tg-confirm[.]com and tgconfirm-repair[.]com | Moscow, Russia in Censys |
80[.]76[.]42[.]108 | Probable historical tgconfirm-repair[.]com origin | Moscow, Russia |
80[.]76[.]42[.]201 | tgconfirm-repair[.]com and tgauth-confirm[.]com | Moscow, Russia |
93[.]170[.]123[.]163 | Historical tgsafeprotect[.]com origin | London, United Kingdom in Censys and IPinfo; Lviv, Ukraine in Shodan |
The available evidence therefore supports describing the infrastructure as heavily concentrated in a hosting ecosystem associated with Russian-addressed network space, with several origins consistently geolocated to Moscow.
A separate host, 77[.]83[.]198[.]160, served the same framework behavior and page assets but belonged to AS59711, associated with HostZealot/HZ Hosting, rather than AS212913. IPinfo geolocated this address to Tallinn, Estonia. It is treated as a related deployment rather than one of the seven domain-origin mappings. The available evidence does not establish whether it was operated by the same actor.
8. Assessment
The evidence supports a long-running regional Telegram OTP-phishing framework or activity cluster, with successive domains and overlapping infrastructure from at least October 2024 through July 2026. The strongest links are exact code reuse, repeated individualized URL design, consistent response headers, shared origins and certificates, and synchronized domain provisioning.
Russia was the dominant target country in the available data, but Belarus and Kazakhstan appeared repeatedly across different domain generations. The GTI submission pattern broadly aligned with the country encoded in the phone number, supporting the assessment that many URLs were encountered by people or systems in the intended country.
RESIDENT.NGO does not attribute this activity to a specific threat actor. Shared code may be reused by one operator, sold to multiple customers or deployed by a service provider. Hosting concentration, registrar choice and Russian-language targeting do not establish the operator’s nationality or institutional affiliation.
8.1 Key limitations
- A phone number embedded in a URL is strong evidence of individualization, but the dataset cannot confirm that every generated link was delivered to its intended person.
- GTI first-submission dates may post-date delivery and should not be treated as exact attack dates.
- GTI country and city fields describe the apparent submitting network, which may be a recipient, analyst, gateway, VPN or automated service.
- Current DNS and registration records can reflect later re-registration, parking or repurposing; historical campaign assessment relies on records captured during the relevant period.
- Exact code was not captured for every domain, so the report separates code-confirmed, predecessor and operational associations.
9. Detection opportunities and indicators
The most durable hunting signal is the combination of a deceptive userinfo URL and a Base64 value that decodes to a plausible telephone number. Individual indicators may be changed or reused, so defenders should combine URL structure, response behavior and infrastructure context.
| Type | Defanged indicator / pattern | Investigative relevance |
|---|---|---|
| Domains | tg-confirm[.]com; tg-repair[.]com; tgsafeprotect[.]com; tgconfirm-repair[.]com; tgauth-confirm[.]com; tgreviewcheck[.]com; tgcheckprotect[.]com | Seven domains assessed in this report. |
| Additional associated domain | tgrenewprotect[.]com | Observed in certificate association with tgreviewcheck[.]com; framework use not confirmed. |
| Confirmed / candidate origins | 45[.]130[.]151[.]58; 45[.]151[.]139[.]71; 45[.]151[.]139[.]84; 45[.]151[.]139[.]85; 80[.]76[.]42[.]108; 80[.]76[.]42[.]201; 93[.]170[.]123[.]163 | Domain-associated infrastructure; confidence varies by row in Section 7. |
| Related deployment | 77[.]83[.]198[.]160 | Same framework behavior on a different hosting provider. |
| Lure pattern | hxxps://telegram[.]org@<domain>/?<Base64(phone)> | URI userinfo deception plus individualized phone token. |
| Direct pattern | hxxps://<domain>/?<Base64(phone)> | Variant without the telegram[.]org@ prefix. |
| Target-state cookie | userID=<Base64(phone)> | Encoded phone reflected into a short-lived cookie. |
| Visitor-geolocation cookie | country_code=<CC> | Apparent visitor IP geography; not the phone-number country. |
| Response selection header | Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model | Distinctive framework-level signal when combined with the URL and content. |
| Cache variation header | Vary: User-Agent, Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model | Supports browser/platform-dependent response behavior. |
| Bailout destination | hxxps://telegram[.]org/faq | Used after decoy or confirmation branches; legitimate destination, not malicious by itself. |
Appendix A. Individualized phone numbers observed in GTI
The following list contains every distinct phone number decoded from the individualized URLs in the supplied GTI data. Exactly two digits are replaced with ** in a consistent position. Dates are the first GTI submission timestamps, not confirmed delivery dates. The entries should not be interpreted as confirmed compromises.
| First GTI observation | Domain | Country | Masked phone number |
|---|---|---|---|
| 2024-10-22 | tg-confirm[.]com | Russia | +7 929 9** 1059 |
| 2024-10-25 | tg-confirm[.]com | Russia | +7 985 4** 5727 |
| 2025-01-06 | tg-repair[.]com | Russia | +7 914 6** 1629 |
| 2025-01-14 | tg-confirm[.]com | Russia | +7 950 7** 8371 |
| 2025-01-14 | tg-repair[.]com | Kazakhstan | +7 700 3** 6568 |
| 2025-02-05 | tg-confirm[.]com | Russia | +7 923 6** 8860 |
| 2025-02-25 | tg-repair[.]com | Belarus | +375 33 6** 9755 |
| 2025-03-06 | tg-repair[.]com | Russia | +7 919 5** 2133 |
| 2025-05-08 | tg-repair[.]com | Russia | +7 909 0** 1786 |
| 2025-06-16 | tg-repair[.]com | Russia | +7 960 2** 7334 |
| 2025-06-30 | tg-repair[.]com | Belarus | +375 29 5** 6204 |
| 2025-07-17 | tg-repair[.]com | Belarus | +375 33 6** 5379 |
| 2025-08-13 | tg-confirm[.]com | Russia | +7 927 3** 2593 |
| 2025-11-14 | tg-repair[.]com | Russia | +7 962 3** 3091 |
| 2025-11-26 | tg-repair[.]com | Russia | +7 985 2** 7317 |
| 2025-12-03 | tg-confirm[.]com | Russia | +7 928 2** 6549 |
| 2025-12-05 | tg-confirm[.]com | Russia | +7 916 2** 7735 |
| 2025-12-11 | tg-repair[.]com | Russia | +7 911 0** 1725 |
| 2025-12-15 | tg-repair[.]com | Russia | +7 959 1** 3701 |
| 2025-12-16 | tg-confirm[.]com | Russia | +7 951 0** 5754 |
| 2025-12-23 | tg-confirm[.]com | Russia | +7 927 3** 1293 |
| 2026-01-05 | tg-confirm[.]com | Russia | +7 918 7** 3652 |
| 2026-01-26 | tg-confirm[.]com | Russia | +7 984 1** 1065 |
| 2026-02-05 | tgsafeprotect[.]com | Russia | +7 911 1** 1462 |
| 2026-02-08 | tg-confirm[.]com | Russia | +7 910 4** 4342 |
| 2026-02-11 | tgconfirm-repair[.]com | Russia | +7 919 1** 2117 |
| 2026-02-13 | tgconfirm-repair[.]com | Russia | +7 978 5** 3509 |
| 2026-03-02 | tgconfirm-repair[.]com | Russia | +7 925 6** 7730 |
| 2026-03-05 | tgconfirm-repair[.]com | Russia | +7 985 6** 4522 |
| 2026-03-09 | tgsafeprotect[.]com | Russia | +7 961 7** 6673 |
| 2026-03-12 | tgsafeprotect[.]com | Russia | +7 964 9** 8058 |
| 2026-03-13 | tgconfirm-repair[.]com | Russia | +7 928 2** 7541 |
| 2026-03-13 | tgconfirm-repair[.]com | Russia | +7 903 7** 7037 |
| 2026-03-19 | tgconfirm-repair[.]com | Russia | +7 920 2** 1756 |
| 2026-03-19 | tgconfirm-repair[.]com | Russia | +7 985 7** 7393 |
| 2026-03-21 | tgconfirm-repair[.]com | Russia | +7 920 5** 5551 |
| 2026-03-24 | tgconfirm-repair[.]com | Russia | +7 925 3** 4221 |
| 2026-03-25 | tgconfirm-repair[.]com | Russia | +7 936 3** 3000 |
| 2026-04-08 | tgconfirm-repair[.]com | Russia | +7 914 4** 0832 |
| 2026-04-13 | tgconfirm-repair[.]com | Russia | +7 904 0** 9915 |
| 2026-04-17 | tgconfirm-repair[.]com | Russia | +7 903 5** 1495 |
| 2026-04-24 | tgconfirm-repair[.]com | Russia | +7 915 5** 8857 |
| 2026-04-27 | tgconfirm-repair[.]com | Russia | +7 920 2** 1223 |
| 2026-04-29 | tgconfirm-repair[.]com | Russia | +7 962 5** 3014 |
| 2026-05-08 | tgsafeprotect[.]com | Russia | +7 906 2** 7884 |
| 2026-05-15 | tgconfirm-repair[.]com | Russia | +7 988 9** 5500 |
| 2026-05-20 | tgconfirm-repair[.]com | Russia | +7 909 9** 3898 |
| 2026-05-25 | tgconfirm-repair[.]com | Russia | +7 931 2** 8122 |
| 2026-06-03 | tgauth-confirm[.]com | Kazakhstan | +7 701 1** 0821 |
| 2026-06-04 | tgreviewcheck[.]com | Russia | +7 917 9** 6702 |
| 2026-06-10 | tgauth-confirm[.]com | Russia | +7 927 4** 0101 |
| 2026-06-11 | tgreviewcheck[.]com | Russia | +7 965 9** 1404 |
| 2026-06-15 | tgreviewcheck[.]com | Russia | +7 999 4** 8106 |
| 2026-06-16 | tgreviewcheck[.]com | Russia | +7 914 0** 3110 |
| 2026-06-17 | tgauth-confirm[.]com | Belarus | +375 44 7** 7343 |
| 2026-06-19 | tgreviewcheck[.]com | Russia | +7 926 1** 7470 |
| 2026-07-06 | tgcheckprotect[.]com | Russia | +7 904 0** 9797 |
| 2026-07-08 | tgcheckprotect[.]com | Russia | +7 916 3** 9000 |
| 2026-07-15 | tgcheckprotect[.]com | Russia | +7 962 1** 9815 |
| 2026-07-16 | tgcheckprotect[.]com | Belarus | +375 25 9** 2584 |
| 2026-07-16 | tgcheckprotect[.]com | Russia | +7 980 5** 1883 |
| 2026-07-18 | tgauth-confirm[.]com | Russia | +7 930 1** 8953 |
| 2026-07-22 | tgcheckprotect[.]com | Belarus | +375 33 3** 3065 |
| 2026-07-22 | tgcheckprotect[.]com | Belarus | +375 33 3** 8309 |
Appendix B. Source summary
This report was prepared from the following supplied datasets and case materials:
- RESIDENT.NGO technical case report and incident artifacts for tgcheckprotect[.]com.
- GTI/VirusTotal URL records for the seven domains, including response headers, cookies, page metadata and first-submission timestamps.
- GTI/VirusTotal domain and RDAP records.
- GTI URL submission objects and anonymized source keys.
- Censys and Shodan domain and host exports.
- IPinfo records for selected origins and the related 77[.]83[.]198[.]160 deployment.
Data cutoff: 22 July 2026. All dates are UTC unless otherwise stated.