Introduction
In July 2026, RESIDENT.NGO investigated an instance of a cloaked Telegram phishing campaign used against an exiled Belarusian activist living in Lithuania. Delivered in a private Telegram Secret Chat as a fake Telegram security alert, the phishing link led to a convincing Telegram-themed page designed to capture one-time login codes in real time. The operation’s defining feature was not the phishing page itself but its browser- and device-aware cloaking: visitors using browser and platform configurations accepted by the server, together with a syntactically valid token, could receive the phishing interface, while other configurations—including many automated scanners and some common desktop browsers—were shown decoy content or redirected to Telegram’s legitimate website. This report examines the operation’s tradecraft, technical implementation, and defensive implications. RESIDENT.NGO has not attributed the activity to a specific threat actor. However, our investigation identified what appears to be part of a broader Telegram phishing campaign targeting users across several countries. We present our findings on that campaign in a separate publication.
Key findings
- A Belarusian activist in exile in Lithuania was targeted with a link — delivered inside a fake Telegram “security” warning — designed to intercept their Telegram login code and take over their account in real time.The target recognized the attack immediately, entered no credentials, and referred the material to RESIDENT.NGO for analysis.
- The phishing link was delivered through a private Telegram Secret Chat from an unfamiliar account created in June 2025 and registered to a Kazakhstani phone number. The Secret Chat delivery method and foreign-registered sender account complicated evidence preservation, reporting, and forensic examination.
- Each observed phishing link was individualized with a phone number encoded in its token and protected by browser- and device-aware cloaking to selectively deliver content. Only visitors using an eligible browser and platform profile and presenting a syntactically valid numeric token were shown the phishing page.
- The phishing site (tgcheckprotect[.]com) is a cloaked Telegram login-code (OTP) harvester engineered for real-time account takeover.
- The operation steals Telegram login codes but does not deploy malware.
- To reduce the likelihood of automated detection, the lure message replaces selected Cyrillic characters with visually similar Latin and Greek letters and inserts invisible Unicode separators. To a human reader, the text appears unchanged; to a keyword scanner, it is no longer an exact match.
- The operator appears to monitor who opens the link and adapt their lures accordingly. A follow-up message echoes the recipient’s own device and location in a fabricated “suspicious activity” alert, increasing the pressure to revisit the phishing page and complete the attack.
1. The lure: an unsolicited link in a secret chat
The activist received an unsolicited message in a Telegram Secret Chat — Telegram’s end-to-end encrypted, device-specific messaging mode — from an unfamiliar account. The message contained a link that appeared, at first glance, to point to Telegram’s website. The deception relied on a long-standing URL obfuscation technique. The attackers placed telegram.org before an @ symbol, followed by the actual malicious domain. While the address appeared to begin with Telegram’s legitimate domain, everything before the @ was treated as user information rather than the destination. The browser therefore ignored the telegram.org prefix and connected to the attackers’ server instead.
The operation generates individualized phishing links, each embedding the intended target’s phone number. The phishing URL takes the form https://telegram.org@tgcheckprotect[.]com/?Mzcw…. The Base64-encoded value following /? decodes to the target’s telephone number. The server uses this value to personalize the phishing page, displaying the target’s own number as a trust-building cue intended to make the fake Telegram security prompt appear authentic.
1.1 The message: a fake security warning, built to slip past filters
The phishing link was delivered in a fabricated Telegram security notice addressed to the target by name. The message falsely claimed that the account had violated Telegram’s rules and attracted “numerous complaints,” resulting in temporary restrictions. It instructed the recipient to follow the embedded link to “confirm” the account or risk having it blocked. Exact English translation of the lure message:
This message was sent automatically in order to ensure the maximum security of your account.
Hello, [name redacted]
Your account violates Telegram’s rules. We are very sorry that you have encountered this. Unfortunately, our anti-spam system sometimes reacts excessively harshly to certain actions.
Due to the receipt of numerous complaints about your account, we are forced to impose temporary restrictions. If you believe that the restriction of your account is a mistake, please follow the link and confirm your account:
https://telegram.org@tgcheckprotect[.]com/?Mzcw…
If this message is ignored, the current account may be blocked for security purposes.
Yours sincerely,
The Telegram team.
Figure 1: Lure message received by the target (illustrative reconstruction)
The lure message itself was engineered to evade automated detection. Throughout the Russian text, approximately one hundred Cyrillic characters were replaced with visually indistinguishable Latin and Greek homoglyphs—for example, a Cyrillic “а” replaced with a Latin “a,” or a Cyrillic “о” with a Greek omicron. To a human reader, the message remained perfectly legible; to a keyword-based filter, many expected words no longer existed as exact character sequences.
The operators also inserted invisible Unicode control characters into the greeting and sign-off, breaking up otherwise recognizable template phrases without altering their appearance. Together, these obfuscation techniques allowed the message to appear ordinary to its intended recipient while frustrating straightforward string- and keyword-matching by automated detection systems.
1.2 A second message: the target’s own visit turned into bait
After the link was opened, the operator sent a second message — in clean Cyrillic, without the first message’s obfuscation — styled as an alert about an “unfinished account confirmation” and an “attempt to remove the block.” It recited the exact fingerprint of the visit: timestamp, device, and connection location/ASN, then repeated the same lure link. This creates a self-reinforcing trap: opening the first link generates the “suspicious activity” the second message warns about, pressuring a hesitant target to return and complete the step they abandoned. It also means that merely opening one of these links hands the operator a live record of the visitor’s device and network — a reason for potential targets and analysts alike to treat the links as hostile and examine them only from controlled environments.
Figure 2: Follow-up “unfinished account confirmation” message received by the target (illustrative reconstruction)
1.3 Why a secret chat?
The decision to deliver the phishing link via a Telegram Secret Chat, rather than an ordinary cloud chat, appears deliberate and provides several operational advantages. The delivery method complicates incident response: Secret Chat messages cannot be forwarded and screenshots are restricted. Self-destruct timers may further reduce the available evidence, while extracting artifacts such as the sender’s account identifier from the device may require specialized mobile forensic techniques beyond the reach of most victims and civil-society organizations.
2. How the site cloaks its phishing page
The operators invested most of their effort not in the fake page but in controlling who is allowed to see it. RESIDENT.NGO’s testing found that the site inspects each visitor’s browser and device and responds differently. The server uses three signals to determine the response path: the browser’s User-Agent, the declared platform client hint, and the validity of the supplied token format. Depending on the combination of these inputs, the visitor is routed to one of several outcomes:
| Client / condition | Deciding signal | Delivered |
| Firefox (any OS) | User-Agent contains “Firefox” | 302 → real telegram.org/faq |
| Windows Chromium | Sec-CH-UA-Platform: “Windows” | 403 forged Cloudflare decoy |
| Linux/Android Chromium, or Safari/WebKit | platform ≠ Windows, UA ≠ Firefox | 200 OTP-harvest payload |
| …any of the above payload-eligible clients, but malformed token | token does not decode to digits | hold-loop → “confirmed” → real telegram.org |
Figure 3: Server delivery logic
The result is a phishing site that may appear benign to automated scanners and analysts using non-eligible browser configurations, while serving the phishing interface to eligible clients presenting a well-formed phone-number token. An analyst accessing the link from a non-whitelisted browser or an automated scanner retrieving the page may be shown the legitimate Telegram website or a generic error message, leading to the incorrect conclusion that the link is harmless.
3. How the phishing page works: stealing the code in real time
Telegram protects account logins with a one-time authentication code sent to the account owner whenever a new sign-in is attempted. This phishing operation was designed to capture that code in real time, while it remained valid, enabling immediate account takeover.
3.1. Page design
The phishing page closely imitates Telegram Web, Telegram’s browser-based client at web.telegram.org — one of the few places where entering a login code in a browser is a legitimate part of the sign-in process. . It uses the title “Telegram Web”, Telegram’s favicon, and the familiar animated Lottie paper-plane graphic (idle.json) to reinforce the appearance of legitimacy.
Figure 4: Phishing page served to the target
Server-side, the page personalizes the interface using the target’s phone number embedded in the phishing URL. It displays the target’s number, informs the visitor that “We have sent you a message in Telegram with the code,” and presents a five-digit login-code field (name=”comment”). Once five digits have been entered, the form is submitted automatically without requiring further user interaction.
3.2 Exfiltration and authentication relay
When the victim submits the login code, the browser issues a POST request to /?<token> containing the parameters comment=<code> and button_ok=OK. If the submitted code cannot be used, the server responds by re-rendering the page with an “Invalid code” error, allowing the phishing flow to continue without revealing the failure.
The phishing kit functions as a real-time one-time password (OTP) relay. The operator already knows the target’s phone number from the personalized phishing link. After the victim reaches the page, the operator initiates a legitimate Telegram login attempt, causing Telegram to send a genuine authentication code to the victim. Believing the page to be authentic, the victim enters that code into the phishing form, where it is immediately relayed to the operator and used to complete the Telegram login before the code expires.
During analysis, submitting a test code resulted in the page being re-served with an “Invalid code” message, behavior consistent with server-side validation of the supplied code. No evidence was observed of malware delivery, APK downloads, droppers, or other secondary payloads. This branch of the operation appears to be dedicated exclusively to harvesting Telegram authentication codes for account takeover.
Figure 5: Phishing page serving “invalid code” message
3.3 Bailout branch: fingerprint collection and analysis evasion
Requests containing a malformed token — one that does not Base64-decode to a numeric string — are not served the phishing payload. Instead, the server returns a minimal 56-byte holding page consisting solely of a one-second HTML meta refresh (<meta http-equiv=”refresh” content=”1″>). During this holding loop, the server requests additional browser fingerprinting data by advertising Accept-CH headers for Sec-CH-UA-Platform-Version and Sec-CH-UA-Model.
Once the browser supplies the requested client hints, the holding loop resolves to a reassuring page displaying the confirm.json Lottie animation (“Confirmed!”) alongside the message: “Your account is not required for confirmation. Thanks for using Telegram.” After a ten-second delay, the page automatically redirects the visitor to Telegram’s legitimate FAQ (telegram.org/faq).
Figure 6: Phishing page serving “Your account is not required for confirmation. Thanks for using Telegram” message
This behavior is consistent with an analysis-evasion mechanism. Clients that do not provide the expected browser fingerprint — such as automated URL scanners, command-line tools, or incomplete browser emulators — remain trapped in the refresh loop and never receive the final response. By contrast, a fully featured browser discloses additional fingerprinting information, is shown reassuring content, and is ultimately redirected to Telegram’s legitimate website. This behavior reduces the likelihood that casual inspection or automated analysis will identify the link as malicious.
3.4 Token and session mechanics
- Phone-number token. The query parameter Base64-decodes to the target’s phone number, which the server extracts and renders into the phishing page. For clients that have already passed the browser and platform gating, token format determines whether the server presents the phishing payload or the malformed-token bailout branch. The decoded value itself is not validated: arbitrary, well-formed phone numbers are accepted and rendered. This behavior indicates that the site functions as a generic per-target page generator rather than relying on a predefined list of authorized victims.
- userID session cookie. The server reflects the Base64-encoded phone-number token into a Set-Cookie header (userID=<Base64-phone>), using it as a session identifier. Observed cookie lifetimes were short, suggesting a temporary session state.
4. Infrastructure and tradecraft
- The phishing domain tgcheckprotect[.]com was registered on 2026-06-24 at 05:29 UTC through PDR Ltd. d/b/a PublicDomainRegistry.com (IANA registrar ID 303). PDR’s own website still describes it as a wholly owned Endurance subsidiary. Endurance was acquired and combined with Web.com to create Newfold Digital. As of December 2025, Newfold described itself as backed by the US private-equity firms Clearlake Capital Group and Siris Capital Group. The precise fund-level shareholding is private, but there is no apparent Russian ownership in this chain. PDR’s current legal terms add some complexity: customers in India contract with Endurance International Group (India) Private Limited, while customers outside India may contract with P.D.R Solutions (U.S.) LLC. It is registered for a one-year term expiring 2027-06-24, with registrant details redacted for privacy and status clientTransferProhibited. Authoritative nameservers were Cloudflare (sreeni.ns.cloudflare.com, tony.ns.cloudflare.com), consistent with the DNS-only (unproxied) configuration described above; DNSSEC was not enabled. The registration occurred approximately two hours before issuance of the domain’s Let’s Encrypt certificate (2026-06-24 07:33 UTC), consistent with rapid, coordinated same-day provisioning and placing the front-end setup roughly two and a half weeks before the operation. The single-year registration with no renewal history is consistent with disposable, single-campaign infrastructure. Registration data is drawn from RDAP and reflects registrar-supplied values, which are not independently verified.
- DNS delegation without edge proxying. The domain’s authoritative nameservers are Cloudflare (tony.ns.cloudflare.com, sreeni.ns.cloudflare.com), confirming the zone is managed through a Cloudflare account. However, the A record for tgcheckprotect[.]com resolves directly to the origin (45.130.151.58) rather than to a Cloudflare anycast address. Had the record been proxied, public resolvers would return a Cloudflare edge IP and the origin would remain concealed; the return of the true origin indicates the record is in DNS-only mode with no Cloudflare edge in the request path. This corroborates the forged-fronting finding below: the Cloudflare appearance is cosmetic — genuine Cloudflare DNS is used, but traffic is not proxied and the spoofed Cloudflare headers are emitted by the origin itself. The exposure of the origin may reflect a misconfiguration, or a deliberate choice to preserve a direct, unmediated path to the origin for the fingerprinting and code-relay logic, which an intervening proxy could disrupt or log. Regardless of intent, the unproxied record is what enabled direct attribution of the hosting infrastructure.
- Origin hosting and attribution. The origin IP (45.130.151.58) geolocates to Moscow, Russia, with reverse DNS 684877.myvds.top — a hostname within the provider’s own myvds.top infrastructure domain, not a separate legal entity — and falls within AS212913. The specific RIPE inetnum (45.130.151.0/24, netname RU-TIMEHOST-20201103) is set to country: RU and assigned to Time-Host Ltd, with all administrative, technical, and abuse contacts resolving to a single company role object ([email protected]); no natural-person contact is exposed at the netblock level. Time-Host Ltd is a UK-registered private company (company no. 17103685) at 128 City Road, London EC1V 2NX — an address of a type commonly associated with company-formation and virtual-office services. Per Companies House, the company was incorporated only on 19 March 2026, and its sole declared Person with Significant Control is Mykhailo Hornostai (born May 1994), a Ukrainian national resident in Ukraine, holding 75% or more of shares and voting rights and serving as director and secretary. This aligns with the autonomous system’s historical registration to the Ukrainian sole proprietor “FOP Hornostay Mykhaylo Ivanovych,” indicating the UK company looks like a recently created corporate wrapper over a pre-existing Ukrainian hosting operation — a reading reinforced by the RIPE organisation and contact objects for this block having been created on 2026-03-20, the day after incorporation. Despite this Ukrainian ownership, the service is operationally oriented toward the Russian market (ruble pricing, SBP payment support, data processing under Russian Federal Law 152-FZ, primarily Russian-language site) with infrastructure physically located in Russia. The recent UK incorporation, set against branding claiming many years of operation, means the registration jurisdiction should not be taken as indicative of where the operation’s staff, servers, or banking actually reside. Beneficial-ownership details above are drawn from the Companies House Persons with Significant Control register.
- Live phishing content served at /login; decoy gating applied at the site root. A Censys scan on 2026-07-22 retrieved a live Telegram-branded credential-harvesting page at https://45.130.151[.]58/login (HTTP 200), while the same scanner was redirected from the site root to https://telegram.org/faq. As both requests originated from the same fingerprint-less automated scanner, the decoy redirect appears to be gated at the entry path rather than applied uniformly, with the deep-link path serving the kit directly. The page is a hand-assembled clone (jQuery, relative /static/ asset references) presenting a phone-number entry step consistent with the first stage of an adversary-in-the-middle flow that relays the number to Telegram to trigger a legitimate login code. The country selector defaults to “Russian Federation”; the Kazakhstan entry (country code +7) is commented out of the selector markup while the Russian Federation entry (also +7) is retained as the default. The same root-redirect behaviour was independently observed by a Shodan scan on 2026-07-09, and the host was still serving on 2026-07-22, indicating persistence of at least two weeks. This content was observed by third-party scanners rather than during first-party testing, and path-level gating may change between scans; it is reported as the behaviour observed at the time of scanning rather than a fixed property.
- Direct SSH exposure. The origin exposes OpenSSH 8.9p1 (Ubuntu package 3ubuntu0.16, indicating Ubuntu 22.04 LTS) on non-standard TCP port 58654. The server host key (ECDSA P-256, SHA-256 36fa2afc2bce445541556f3c12c2b4b3451f9378a4d5a0810fab29d353530137) and SSH HASSH (41ff3ecd1458b0bf86e1b4891636213e) are recorded for reference.
- Certificate transparency timeline. The HTTPS listener presents a Let’s Encrypt certificate (EC P-256; leaf SHA-256 a43ed5cdaaf5a061059c9c33d36f5759aa8bc8fd86abe568a3bd5180513a1ff4) logged on 2026-06-24 at approximately 08:31 UTC across seven Certificate Transparency logs. Combined with the nginx 1.31.2 build (released 2026-06-17), this places provisioning of the HTTPS front in the third-to-fourth week of June 2026, roughly two-and-a-half weeks before the operation, and provides multiple independent CT sources for monitoring any reissuance.
- Forged Cloudflare fronting. The origin responds with Server: nginx/1.31.2 while manually emitting Cloudflare-specific headers (CF-RAY, NEL, and Report-To) and serving cloned /cdn-cgi/ error assets. A genuine Cloudflare edge response identifies itself with Server: cloudflare and does not expose the origin’s web server version. The presence of the nginx banner therefore indicates that the Cloudflare fronting is being imitated rather than provided by Cloudflare itself. The reported nginx version (1.31.2) was a current mainline release at the time of analysis and is not inherently suspicious. As with any Server header, however, it should not be treated as authoritative evidence of the underlying software, since the value can be set arbitrarily.
- Fingerprint-aware responses. Across all response branches, the server advertises Vary and Accept-CH headers referencing browser client hints, indicating that response content varies according to browser fingerprinting data. The pages also load a legitimate Cloudflare Web Analytics beacon (410fafc043814dd8bf2090b86a44f4d8), demonstrating that the operators selectively incorporated genuine Cloudflare services alongside spoofed Cloudflare branding.
- HTTP/3 behaviour. The origin advertises HTTP/3 support through Alt-Svc: h3=”:443″. During testing, Safari (macOS and iOS) cached this advertisement and preferentially retried subsequent requests over QUIC. The HTTP/3 endpoint exhibited intermittent connection stalls that were not observed over HTTP/1.1 or HTTP/2. This behaviour appears to be an implementation or availability issue rather than a deliberate content-delivery or cloaking mechanism.
Related infrastructure and broader activity
Retrospective analysis identified a broader set of Telegram OTP-phishing domains using the same or closely related tradecraft from at least October 2024 through July 2026. Four domains were linked through matching application-level code and behaviour; two additional domains appear to represent an earlier framework generation; and one domain is operationally related, although its phishing payload was not captured for direct code comparison. The related activity predominantly targeted Russian telephone numbers, with repeated targeting of Belarusian and Kazakhstani numbers. Most identified candidate origins were hosted within the Time-Host/VPSville infrastructure ecosystem. These findings indicate that the incident documented in this report was one instance of a longer-running regional activity cluster, rather than an isolated phishing deployment. A separate RESIDENT.NGO report provides the complete infrastructure, targeting and timeline analysis.
5. Additional targets identified through VirusTotal URL history
VirusTotal’s recent URL history exposed seven individualized phishing links containing Base64-encoded telephone numbers. Decoding the parameters produced four Russian and three Belarusian numbers. This confirms that the infrastructure was used against multiple targets and supports the assessment that the site operated as a reusable per-target phishing platform rather than a page created solely for the incident documented in this report.
| Date | Decoded phone number | Country |
| 2026-07-22 | +375 33 3** 8309 | Belarus |
| 2026-07-22 | +375 33 3** 3065 | Belarus |
| 2026-07-16 | +7 980 5** 1883 | Russia |
| 2026-07-16 | +375 25 9** 2584 | Belarus |
| 2026-07-15 | +7 962 1** 9815 | Russia |
| 2026-07-08 | +7 916 3** 9000 | Russia |
| 2026-07-06 | +7 904 0** 9797 | Russia |
Two digits in each telephone number have been redacted to limit unnecessary exposure while allowing potential targets to recognize their own number. People who believe they match an entry may contact RESIDENT.NGO for confidential verification.
6. Attribution and limitations
RESIDENT.NGO has not attributed this operation to a specific threat actor. However, the targeting of an exiled Belarusian activist, the use of a private Telegram Secret Chat, and the disposable, foreign-registered sending account are consistent with the types of account-takeover operations that have repeatedly targeted Belarusian civil society. Open-source reputation for the domain and IP was inconclusive at time of writing. The broader set of individualized URLs nevertheless indicates that the infrastructure was not exclusive to the documented activist.
Two additional observations are noteworthy. First, the site functions as a generic per-target page generator rather than a single-use phishing page. It will render the phishing interface for virtually any well-formed phone number embedded in the URL, displaying that number back to the visitor. This design allows the operator to generate individualized lures on demand for multiple recipients beyond the individual documented here.
Second, the server collects geolocation and device information from visitors. Although this data did not affect the content delivered during testing, it is still transmitted to the operator. Because each phishing link is unique to a specific phone number, the collected telemetry can be tied to an individual target rather than an anonymous visitor. While RESIDENT.NGO did not observe how this information was ultimately used, it could provide operators with additional situational awareness or support victim profiling and follow-on operations.
7. Outlook and implications
This case illustrates that some of the most effective attacks against civil society require no malware at all. A single, carefully crafted message — delivered privately and tailored to a specific individual — can be sufficient to compromise an account. In this operation, the technical sophistication lay not in the phishing page itself, but in the surrounding tradecraft: browser-aware cloaking, personalized links, and delivery via Telegram Secret Chats combined to reduce the likelihood of detection while maximizing the chance of success.
For defenders, the principal challenge is the operation’s selective-delivery logic. A link that presents the legitimate Telegram website, a benign error page, or a reassuring message to most visitors can evade automated scanners and casual manual inspection. Effective detection therefore depends on analyzing URL structure, delivery patterns, and hosting infrastructure — not solely the content returned during a single visit. For at-risk users, the defensive guidance is straightforward: never enter a Telegram login code or/and cloud password (2FA) on a page reached through a link, and enable Telegram’s cloud password (two-step verification).
8. Indicators of compromise
| Type | Defanged indicator or pattern | Investigative relevance |
| Phishing domain | tgcheckprotect[.]com | Primary domain used in the investigated incident |
| Origin IPv4 | 45[.]130[.]151[.]58 | Directly exposed, non-Cloudflare origin associated with the domain |
| Personalized lure pattern | hxxps://telegram[.]org@tgcheckprotect[.]com/?<Base64(MSISDN)> | Uses URI userinfo deception and embeds the intended telephone number as Base64 |
| Direct personalized URL pattern | hxxps://tgcheckprotect[.]com/?<Base64(MSISDN)> | Useful for hunting variants that omit the telegram.org@ prefix |
| Phishing submission pattern | POST /?<Base64(MSISDN)> with comment=<5-digit-code>&button_ok=OK | Captures the Telegram login code entered by the visitor |
| Target-state cookie | userID=<Base64(MSISDN)> | Reflects the phone-number token into a short-lived cookie |
| Visitor-geolocation cookie | country_code=<CC> | Records apparent visitor IP geography; not the target phone-number country |
| Relevant paths | /login, /noverification | /login exposed a Telegram-themed login flow; /noverification was used in the reassuring bailout branch |
| Bailout behaviour | malformed token → one-second meta-refresh loop → fake confirmation → hxxps://telegram[.]org/faq | Helps identify cloaking and analysis-evasion behaviour even when the OTP page is not returned |
| Distinctive response headers | Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model | Repeated across the phishing responses and useful as a framework-level hunting signal |
| Distinctive cache variation | Vary: User-Agent, Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model | Indicates response selection based on browser and device characteristics |
| TLS certificate SHA-256 | a43ed5cdaaf5a061059c9c33d36f5759aa8bc8fd86abe568a3bd5180513a1ff4 | Supports certificate-transparency and historical host correlation |
| SSH ECDSA host-key SHA-256 | 36fa2afc2bce445541556f3c12c2b4b3451f9378a4d5a0810fab29d353530137 | Useful for correlating the same server if its IP address or domain changes |
| Delivery vector | Telegram secret chat; sender acct reg. 2025-06, KZ number | Unknown sender; targeted delivery |
| Lure obfuscation | homoglyph substitution + invisible chars (U+206B/2061/2062) | Evades keyword/text filters |
| Server string | nginx/1.31.2 | Seems to be real, then-current version; genuine Cloudflare would report ’cloudflare’ instead; freely spoofable |
8. MITRE ATT&CK
| Tactic | Technique |
|---|---|
| Resource Development | T1583.001 Acquire Infrastructure: Domains · T1585 Establish Accounts |
| Initial Access | T1566.002 Phishing: Spearphishing Link |
| Defense Evasion | T1656 Impersonation · T1036 Masquerading · T1480 Execution Guardrails (selective delivery) |
| Credential Access | T1111 Multi-Factor Authentication Interception |