Crypto Compensation Scam: Fake BTC Payout Lure Abusing Survey & Payment Flows

Anurag GawandeLeave a comment

Overview

I recently came across a message containing the following link:

hxxps://yandex[.]com/poll/PdZ7vgekGrNakuXZcpiB6b

At first, it didn’t look suspicious. It opened as a simple survey/poll page. But as I continued, the flow quickly shifted into a crypto reward scenario, claiming that I was eligible to receive a Bitcoin compensation payment.

And as expected with these kinds of lures, there’s a catch.

Before you can withdraw the funds, you’re asked to pay a small “commission” fee.

Full Scam Walkthrough (Video)

This gives a better idea of how smoothly the entire flow is designed to push the victim toward payment.

Infection / Lure flow

1. Initial Entry (Survey / Poll Page)

The flow starts with a Yandex poll link, which works as a kind of entry point.

This step likely serves multiple purposes. It helps make the interaction feel legitimate since it’s hosted on a known platform. It may also act as a basic filter to distinguish real users from automated systems. More importantly, it sets up the next stage of redirection.

2. Fake Bitcoin Compensation Page

After interacting with the poll, I was redirected to a page that looks like it belongs to a Bitcoin related service.

The page presents a sense of urgency by claiming that a new transaction of 0.943 BTC has been created and already marked as approved. It then introduces pressure by warning the user to withdraw the funds within 24 hours, a tactic commonly used to rush victims into taking immediate action without verifying the legitimacy of the claim.

This is where the emotional hook kicks in. Seeing a large amount like 0.943 BTC immediately grabs attention.

3. Social Engineering via Chat Assistant

Then a chat window appears, introducing a support agent.

The message explains that to complete the payment process, you need to register your profile in a compensation system. It sounds procedural and official, which is exactly the intention.

Shortly after, the real objective becomes clear.

You are asked to:

Pay $67 for legal profile registration services

4. Payment Gateway

Clicking the payment link takes you to a dedicated payment page.

Here, everything is carefully designed to appear legitimate and trustworthy. The page shows a specific payment amount of $67, provides a Bitcoin payment option via a QR code, and displays a wallet address to reinforce authenticity. On top of that, a countdown timer indicating invoice expiry adds urgency, subtly pressuring the user to complete the transaction quickly without questioning its validity.

The design mimics real crypto payment processors, which helps reduce suspicion.

The flow is quite structured and intentional.

It starts by engaging the user through a trusted platform, which lowers initial suspicion. Then it introduces a high-value crypto reward, creating excitement. A chat assistant adds a layer of interaction, making the process feel guided and legitimate.

Finally, the user is asked to pay a relatively small fee to unlock a much larger reward.

This is essentially an advance fee scam, adapted to fit into a crypto themed narrative.

Additional Variant Observed (Octa-Themed Flow)

While analyzing further, I encountered another link that follows the same backend scam logic, but with a different initial presentation.

The flow eventually leads to the same outcome, pay a commission to withdraw BTC.

Variant Walkthrough (Video)

1. Fake Account / Transfer Notification

This version starts with a fake dashboard impersonating Octa.

The page further attempts to lure users by displaying a message stating “You have a new money transfer”, along with a balance of 1.824 BTC. This presentation is crafted to create excitement and curiosity, making it seem like the user has unexpectedly received funds, while subtly encouraging them to engage with the page and follow the next steps without questioning its authenticity.

2. Fake Login & Temporary Password Flow

The user is asked to log in using a temporary password.

This step closely mimics real authentication flows to build trust and credibility. It displays a temporary password, includes an OTP style input field, and reinforces legitimacy with messaging like “Do not share this password!”. These familiar elements are designed to make the process feel secure and authentic, lowering suspicion while guiding the user further into the flow.

3. Transaction Dashboard

After logging in, the user is presented with a dashboard that appears highly convincing, displaying details such as the sender labeled as Octa, a balance of 1.824 BTC, and a status marked as paid. The layout, wording, and transaction details are all carefully crafted to create a sense of authenticity, making the entire interface look legitimate and encouraging the user to trust the process without suspicion.

4. Commission Justification

Before allowing any withdrawal, the platform introduces an additional requirement in the form of a commission fee of around $69, accompanied by an explanation about wallet limits and transfer rules. This step is designed to appear reasonable and procedural, giving the impression that the fee is a standard part of the process while subtly nudging the user to make a payment in order to access the supposed funds.

5. Payment Page

Just like the initial flow, the process ultimately leads to a familiar payment stage, presenting a Bitcoin payment request along with a QR code and a wallet address for convenience. An expiry timer is also displayed to create urgency, pressuring the user to act quickly and complete the payment without taking the time to question the legitimacy of the request.

What stands out is how the attackers reuse the same core scam but change the entry point.

I also looked into related activity on URLScan and found similar lures being actively scanned in the last couple of days, which indicates that this is not a one off campaign but something currently active and evolving.

Indicators of Compromise (IOCs)

URLs

Along with the observed infrastructure, I checked domain registration timelines, which further indicate that this campaign is relatively recent and actively being used.

  • cosibas[.]site – Registered on 2026-01-30
  • paybits[.]cc – Registered on 2026-02-02

hxxps://yandex[.]com/poll/PdZ7vgekGrNakuXZcpiB6b
hxxps://yandex[.]com/poll/GjSFvwyKcmEMXpzm6yDExc
hxxps://cosibas[.]site/bloc/anketa-sent.html
hxxps://cosibas[.]site/octa/
hxxps://paybits[.]cc/payment/

Kraken Darknet Access via Clearnet Gateways

Anurag GawandeLeave a comment

Introduction

Recent threat intelligence analysis uncovered a login surface associated with the Kraken darknet ecosystem that is simultaneously exposed through traditional clearnet domains and Tor onion services.

The CAPTCHA workflow, authentication layout, and visual structure appear nearly identical across both environments, indicating a shared deployment rather than independent mirrors.

Closer inspection of client side behavior, background network requests, embedded routing logic, and indexed clearnet infrastructure reveals that the public web instance behaves not as a standalone marketplace, but as a gateway layer positioned in front of onion hosted backend services.

Clearnet Authentication Flow and Backend Coordination

Credential submission from the clearnet interface occurs through a local POST endpoint (entry/login), meaning authentication data is first delivered to the clearnet server rather than directly to an onion server.

At the same time, the page issues a background request to an internal routing component (modules/onion_servers/take_server.php). This behavior indicates that session binding or mirror selection takes place before authentication completes, a pattern consistent with broker like access layers used to shield hidden backend infrastructure.

Client side scripting implements hashing and cookie persistence mechanisms that coordinate session state and routing identifiers across requests, further reinforcing the interpretation that the clearnet layer performs pre-authentication orchestration rather than simple credential validation.

Session Routing and Onion Backend Telemetry via Cookies

Captured HTTP cookies from the clearnet authentication workflow expose additional internal routing and infrastructure metadata that is not visible in the user interface.

Observed cookie values include:

Technical Interpretation

The structure and naming of these cookie parameters reveal multiple layers of backend coordination:

  • Tor aware routing indicators: Fields such as tor_scheme_id, tor_port, and onion_server_id strongly suggest that the clearnet gateway is dynamically binding user sessions to specific hidden service endpoints.
  • Session orchestration across proxy layers: Identifiers like proxy_cf_session_id, remote_route, and remote_server_id indicate traversal through intermediary infrastructure, likely used for load distribution, resilience, or service isolation.
  • Referral and discovery tracking: The presence of a clearnet referrer (kraken106[.]com) demonstrates linkage between publicly reachable discovery domains and backend onion infrastructure.

Taken together, these cookie artifacts offer clear, practical evidence of how the underlying flow operates. They suggest that authentication is first handled through clearnet session brokers, that individual user sessions are then tied to specific onion based backends, and that routing decisions happen even before credential validation is fully completed.

Embedded Onion Infrastructure and Clipboard Manipulation

Inspection of the clearnet HTML reveals embedded onion addresses referenced directly inside client side logic.

JavaScript within the page intercepts clipboard copy events and transparently replaces known onion domains with alternate mirrors. This behavior is consistent with operational techniques used to maintain mirror redundancy, traffic steering, and controlled user routing inside darknet service ecosystems.

The script attaches a copy event listener to the document and inspects any selected text before it reaches the system clipboard.

If the copied content contains a known onion hostname, the script replaces it with a different hidden service address mapped inside an internal dictionary before writing the modified value to the clipboard.

Public Indexing of Gateway Domains

Multiple clearnet domains serving the CAPTCHA gateway are indexed by public search engines, making the entry surface discoverable outside Tor.

Search results indicate that these domains primarily act as entry points within a broader ecosystem. They serve as accessibility bridges that help new users reach otherwise hidden services, function as discovery surfaces that introduce users to marketplace environments, and operate as routing frontends that ultimately direct traffic toward underlying onion based infrastructure.

Public indexing fundamentally alters the traditional hidden service threat model by exposing the initial access layer to open web reconnaissance and defensive monitoring.

Discovery of Distributed CAPTCHA Gateway Infrastructure

URLScan telemetry reveals a broad cluster of clearnet domains hosting identical CAPTCHA gated login interfaces tied to the same backend ecosystem.

Observed infrastructure includes:

DomainRegistered On
captcha[.]krad2[.]cc2025-11-05
captcha[.]kraba5[.]cc2025-12-15
captcha[.]kraba5[.]atNA
captcha[.]kra52[.]atNA
captcha[.]kra51[.]cc2025-09-26
captcha[.]krafb5[.]atNA
captcha[.]krafb5[.]cc2025-12-31
captcha[.]krabi5[.]atNA
captcha[.]krabi5[.]cc2025-12-23
captcha[.]krabi4[.]atNA
captcha[.]krabi4[.]cc2025-12-23
captcha[.]krabi3[.]atNA
captcha[.]krabi3[.]cc2025-12-23
captcha[.]krafb2[.]cc2025-12-31
captcha[.]krad2[.]atNA
captcha[.]krabi2[.]cc2025-12-23
captcha[.]krabi2[.]atNA
kra46l[.]cc2025-10-27
kra46l[.]atNA
krak45[.]cc2024-12-21
krak45[.]atNA
kra45l[.]cc2025-10-27
kra45l[.]atNA
kra44l[.]cc2025-10-27
kra44l[.]atNA
kcra43[.]cc2025-07-04
kcra43[.]atNA
kraken106[.]com

Structural Observations

The domain cluster demonstrates

  • systematic naming variation
  • numeric rotation patterns
  • mirrored TLD deployment across .cc and .at
  • consistent captcha. subdomain segmentation

These characteristics indicate intentional large scale provisioning designed for redundancy and survivability rather than opportunistic reuse.

Architectural Interpretation

Correlation of routing behavior, session-binding logic, clipboard manipulation, public indexing, and distributed domain infrastructure produces a coherent architectural model.

The service appears to follow a layered access model in which users first interact with a clearnet gateway that assigns routing paths and session identifiers. From there, the core authentication processes and marketplace logic are handled behind onion-based services, while a network of mirrors helps maintain availability, redundancy, and overall resilience.

Relation to Kraken Marketplace Evolution

Open source reporting describes Kraken as a major successor within the Russian language darknet ecosystem, rapidly expanding after prior market disruptions and adopting infrastructure focused on resilience and accessibility.

Rather than relying solely on hidden services, the platform appears to deploy clearnet discovery and routing layers that ultimately funnel traffic toward onion based backend systems.

This hybrid exposure model represents a notable shift in darknet operational design, blending anonymity with controlled public reach.

Detection Status Across Security Telemetry

At the time of analysis, several of the identified clearnet gateway domains remained unflagged by VirusTotal, while a subset had already begun receiving malicious or phishing classifications from individual security vendors.

Indicators of Compromise (IOC)

Clearnet CAPTCHA Gateway Domains listed above. Here is URLScan.io results for searched domains.

Network Endpoints

Authentication Submission

POST /entry/login

Purpose: Credential submission from clearnet login interface prior to backend routing.

Onion Routing Coordination

GET /modules/onion_servers/take_server.php

Purpose: Background request used for mirror selection, session binding, and backend routing orchestration.

Detection Considerations

  • Repeated access to CAPTCHA-prefixed rotating domains
  • HTTP requests to:
    • /entry/login
    • /modules/onion_servers/take_server.php
    • Presence of Tor-routing cookie parameters in web telemetry
    • Clipboard manipulating JavaScript referencing .onion mirrors

Phishing Risk and Gateway Trust Considerations

The clearnet CAPTCHA protected login page that sits in front of the onion backend naturally raises questions about how much it can be trusted with user credentials. The visual similarity between the clearnet and onion interfaces, along with the session binding and routing behavior observed in the background, could indicate a shared and intentionally designed gateway rather than a simple phishing copy. At the same time, this clearnet layer acts as a single interception point where credentials are submitted before any interaction with hidden services occurs, which makes it an ideal location for logging, redirection, or credential collection. The use of rotating gateway domains, mixed security vendor detections, and client side traffic steering logic adds further uncertainty and makes it difficult to determine intent from surface analysis alone. Because of this, the clearnet entry point should be treated as inherently high risk from a defensive perspective, regardless of whether it ultimately connects to genuine onion infrastructure.

Cloudflare Pages “Continue Read” Redirect Kit Abused for Phishing, Adware, and Malware Delivery

Anurag Gawande1 Comment

I identified a long-running redirect infrastructure abusing Cloudflare Pages (pages.dev) to host benign-looking SEO articles (for example, celebrity “net worth” blogs or gaming help content) that display a forced “Continue reading / Continue Read” pop-up shortly after page load.

Once the user clicks the button, the browser is redirected into downstream infrastructure that may lead to:

  • Credential-harvesting phishing pages
  • Adware / PUP installers
  • Trojan or malware droppers
  • Fake browser download lures (observed: Opera-themed “diagnostics” funnel)
  • QR-code / fake CAPTCHA social-engineering pages

More than 250 URLs were observed using the same visual template and behavior, and historical evidence from URLScan shows activity persisting for 5 months, suggesting deliberate reputation building and SEO indexing.

Initial Infection Vector: Benign SEO Content on Cloudflare Pages

The landing pages appear as normal blog articles but automatically display a modal message:

“Continue reading by clicking the button below.”

This design ensures the redirect is user-initiated, helping bypass automated scanners and reputation systems.

Common characteristics

  • Hosted on: *.pages.dev
  • SEO-style article content
  • Modal overlay appears a few seconds after page load
  • Redirect only occurs after button click

Scale, Persistence, and Search Engine Exposure

Across the analyzed samples, more than 250 distinct URLs were identified showing identical UI and UX behavior, indicating the use of the same phishing template or kit deployed across different article topics. The activity has remained visible for approximately five months based on URLScan observations, suggesting persistence rather than short-lived campaigns. Additionally, some of these pages have been indexed in Google search results, significantly increasing the likelihood of exposure to real users and amplifying the overall risk posed by the operation.

Redirect Logic (Click-Gated Pre-Lander Behavior)

The redirect mechanism is implemented using delayed modal display and a click-triggered JavaScript redirect.

Key Observation

Across many different pages, most samples use the same redirect destination inside window.open()

This is important because it shows that the pages.dev sites are probably not standalone phishing pages created one by one. Instead, they appear to work more like traffic pre-landers that quietly direct visitors to a shared backend system. The key= parameter in the URL also looks intentional rather than random, and it is likely being used for tracking or routing within the campaign, possibly as a campaign ID, an affiliate tracking token, or even a value used to classify or group potential victims.

In short:

Multiple benign-looking SEO pages are acting as entry points into a centralized redirect infrastructure.

Central Redirector Role in the Infection Chain

The shared redirect endpoint:

hxxps://preservationwristwilling[.]com/utx3iw6i?key=<token>

likely serves as a Traffic Distribution System (TDS) decision node, responsible for:

  • Geo/IP filtering
  • Proxy/VPN detection
  • User-agent validation
  • Campaign routing
  • Conditional payload delivery

Simplified Kill Chain

Anti-Analysis Behavior: Proxy / VPN Detection

During testing, downstream pages performed VPN/Proxy checks.

If anonymity was detected, the page displayed:

“Anonymous Proxy detected.”

and stopped further redirection.

Security Impact

From a security perspective, this behavior is particularly concerning because it makes deeper analysis much harder. By blocking or redirecting automated environments, it can prevent sandboxes and researchers from ever reaching the real payload, which in turn leads to very low antivirus detection rates. As a result, automated scans may incorrectly appear clean, creating a false sense of safety even though malicious activity may still be present behind the scenes.

Observed Downstream Outcomes

1) Fake File Download Funnel – S3 ZIP Payload

One redirect path showed a “Your File Download Is Ready” page, leading to:

  • Intermediate download host (e.g., loaditfile[.]com)
  • Final payload stored on Amazon S3 (SetupFile-xxxx.zip)

2) Fake Browser Diagnostics – Opera Download Lure

Another branch displayed a fake compatibility/diagnostics score (e.g., 40/100) urging users to:

“Download Opera Browser”

This pattern feels very similar to the affiliate-driven browser installation funnels often seen in malvertising campaigns, where traffic is quietly redirected through multiple steps before reaching the final payload or monetization stage.

3) QR Code / Fake CAPTCHA Social Engineering

Some redirects presented:

  • “Prove you are not a robot”
  • QR code requiring mobile scan

Flows like this are commonly designed to move victims step by step toward the attacker’s real objective. In many cases, the final destination can be a phishing page that steals credentials, a subscription fraud scheme that silently charges the user, or even the delivery of mobile malware disguised as a legitimate download.

Payload Example and Low Detection Context

One observed executable sample (adware/PUP classification):

SHA256: be590100ecdcae5ce4b7b42f87082e201fcb2f38c114c8fbc6640ad9b9a0708a

VirusTotal showed detection

What makes this particularly notable is that the overall setup closely matches how modern malvertising Traffic Distribution Systems (TDS) typically operate. The infrastructure shows several familiar patterns, such as abusing a trusted hosting platform like Cloudflare Pages, allowing pages to be indexed by search engines to attract organic traffic, and using click-gated redirects to evade automated analysis. Behind the scenes, everything appears to funnel through a centralized redirect endpoint where the final payload can be delivered conditionally, depending on the visitor. This kind of design also supports multiple monetization paths rather than a single outcome. Taken together, it suggests we are not looking at just one phishing kit, but a broader shared redirect ecosystem designed to distribute traffic at scale.

Indicators of Compromise (IOCs)

Domain

  • preservationwristwilling[.]com
  • Path: /utx3iw6i
  • Query Parameter: key=<token>
  • loaditfile[.]com

Malicious Sample

  • be590100ecdcae5ce4b7b42f87082e201fcb2f38c114c8fbc6640ad9b9a0708a
  • Windows Executable
  • Classification: Adware/PUP
  • VirusTotal Detection

Network Indicator

preservationwristwilling[.]com/utx3iw6i?key=

URLScan.io search result

This campaign highlights how attackers carefully blend several techniques to stay under the radar and keep their operation running for long periods. By abusing legitimate hosting services, leveraging SEO poisoning to attract real users, using click-triggered redirects to avoid automated detection, and routing visitors through a centralized traffic system, they create a stealthy and resilient infrastructure capable of quietly delivering malware or other malicious outcomes over time

Tycoon 2FA Campaign Abusing *.contractors Domains for Gmail and Microsoft 365 Credential Harvesting

Anurag GawandeLeave a comment

Overview

Over the past few weeks, I have been tracking a credential harvesting campaign that repeatedly abuses newly registered *.contractors domains to deliver Gmail and Microsoft 365/Outlook phishing pages.

While the social engineering lures vary including ICANN email verification, document sharing, and account security prompts. The underlying infrastructure, tooling, and execution flow remain consistent

Based on analysis of the phishing HTML, JavaScript, and runtime behavior, this activity can be attributed with high confidence to the Tycoon 2FA phishing kit, based on its distinctive MFA aware execution flow, client side obfuscation, and anti-analysis tradecraft.

This attribution is supported by distinctive Tycoon specific client side tradecraft, including MFA aware flows, advanced anti-analysis logic, and encrypted runtime loaders, as shown below.

Technical Evidence Supporting Tycoon 2FA Attribution

Analysis of the extracted HTML and JavaScript reveals multiple Tycoon 2FA specific behaviors that go beyond generic phishing kits.

Anti-Analysis & Sandbox Evasion Logic

The phishing pages actively detect analysis environments and developer tools, immediately terminating execution or redirecting the user if detected:

Additional protections disable common inspection techniques:

This multi-layered anti-analysis logic is a well known characteristic of Tycoon 2FA deployments, commonly observed across multiple campaigns leveraging this phishing-as-a-service (PhaaS) framework.

Runtime Debugger Detection & Forced Redirect

The kit also employs debugger timing detection to identify active inspection and force redirection:

This technique is specifically used by Tycoon based phishing frameworks to evade dynamic analysis and sandbox detonation.

ICANN Email Verification Lure

One of the more recent samples impersonates ICANN (Internet Corporation for Assigned Names and Numbers) and claims that the recipient’s email address must be verified to avoid domain-related disruption.

The email states that:

  • The recipient’s email is listed as the owner contact for a domain
  • The address is allegedly unverified or inactive
  • Failure to verify may result in email suspension

A verification link is provided, styled to appear ICANN-related. However, hovering over the link reveals that it actually points to attacker controlled infrastructure hosted outside of any legitimate ICANN or registrar domain. In this case, the observed link resolved to

hxxps://recontact252.bluvias.de/572pectoral/$anurag@malwr-analysis.com

The URL embeds the recipient’s email address directly in the path, a common personalization technique used in targeted phishing campaigns to increase credibility and successful credential submission.

Redirection Flow: CAPTCHA as an Anti-Analysis Gate

Clicking the verification link does not immediately present a login page.

Instead, victims are routed through a fake CAPTCHA / “confirm you’re human” page, which serves as a deliberate execution delay.

This delay is important for two reasons:

  • Automated sandbox services (e.g., URLScan) often complete scanning before the CAPTCHA stage is reached, meaning the actual phishing payload is never rendered during automated analysis.
  • User interaction is required to proceed, filtering out non-human traffic and reducing detection rates.

Final Payload: Gmail & Microsoft 365 Tycoon 2FA Lures

After CAPTCHA completion, victims are redirected to high-fidelity Gmail or Microsoft 365 / Outlook login pages, depending on the campaign variant.

Observed behaviors include:

  • Accurate UI and branding replication
  • Email address prefilled or dynamically referenced
  • Transition into multi-step authentication flows
  • MFA approval interception and credential capture

Despite branding differences, both lures share identical loader logic, obfuscation patterns, and runtime behavior, confirming they are part of the same Tycoon 2FA campaign.

Infrastructure Reuse: *.contractors Domains

Across all observed samples, the campaign consistently abuses freshly registered .contractors domains, often using randomized subdomains and long URL paths.

Examples observed include:

Outlook 

hxxps://datacenter.lonaihoo.contractors/i!2zDbFPEvdm/

hxxps://pytorch.hithomu.contractors/Hik3GWNtRtmoaf@Ul5FNuB3/$bmVzZS5ndW5lckBlZ29uemVobmRlci5jb20=

hxxps://bigbluebutton.seacrevea.contractors/nGPI9ensbX@Y/

hxxps://redoc.kaidaisoo.contractors/Yi@9yUWrVO/

hxxps://firewall.tiostemio.contractors/nu2ATGWco@GZ/

hxxps://pulumi.kaidaisoo.contractors/QBQG4CC@30W/

Gmail 

hxxps://cdnedge.kirosoo.contractors/UyHX5Z5NJWj!i6VTZW5/

hxxps://bscscan.kirosoo.contractors/KQccgiv0@RRZ4xeCQMfRJbnT/

hxxps://copytrade.kirosoo.contractors/m8WqmrYb6lVk7C@9o1Yio/

hxxps://dist.draidatroo.contractors/4!OMtEFiKRQ/

hxxps://boot.lizojea.contractors

hxxps://hashid.draidatroo.contractors/ey!z5jV2w/


Benign Page

hxxps://ide.pishathi.contractors

hxxps://ide.niramio.contractors/

hxxps://js.hithomu.contractors/

hxxps://substack.wifupu.contractors/

hxxps://swap.lizojea.contractors/

hxxps://bandwidth.kioboumu.contractors/tO3v!7gw

hxxps://zip.lucadru.contractors/

Common characteristics observed across these campaigns include domains registered very recently, most notably on 07 January 2026 and 14 January 2026 along with randomized URL paths and identifiers designed to evade detection. Victim email addresses are embedded directly within the URLs to personalize lures and enable tracking.

Observed Evasion via Decoy Landing Pages

When analysis is detected or when execution fails, the infrastructure does not return an error page.

Instead, victims or scanners are redirected to to benign decoy landing page templates, including:

  • Finquick
  • Flowguide
  • Desio Copilot

These templates act as decoy content, helping:

  • Evade automated detection
  • Reduce suspicion during manual review
  • Prolong domain lifespan

This fallback behavior has been repeatedly observed in Tycoon-based phishing campaigns.

Campaign Scope: *.contractors Domains Observed on URLScan

During this investigation, I identified multiple .contractors domains associated with this campaign through URLScan submissions and pivoting.

A consolidated list of all observed .contractors domains, along with scan links and timestamps, will be provided below for reference and detection purposes.

https://urlscan.io/result/019c0245-d376-75f6-9cb1-61ea3d390d5b/

https://urlscan.io/result/019c03c8-00f8-718f-b45a-af4fd080112e/

https://urlscan.io/result/019c046b-012c-740e-b96a-cf111e169b0a/

https://urlscan.io/result/019bc8b1-63f4-765c-96a1-46d406426c1e/

https://urlscan.io/result/019bfa8b-127e-7718-abad-b1390d3c9e08/

https://urlscan.io/result/019bec78-0eaf-70c9-bbda-d839444f8120/

https://urlscan.io/result/019bfeea-9343-713f-8cf8-cd62c3f10a01

https://urlscan.io/result/019bd770-5232-7789-807b-127ca1422e2b

https://urlscan.io/result/019c0616-3df5-7178-a87a-f80358df27b0/

This activity represents a coordinated, MFA aware phishing campaign, not isolated incidents.

While this analysis identifies multiple .contractors domains and consistent infrastructure patterns, it is likely that additional domains and variants are in use beyond those documented here. The findings in this post are based on artifacts and infrastructure observed within the scope of URLScan, and the full extent of the campaign may be broader.

Additional Infrastructure Observed

During continued investigation, I identified additional, distinct domains serving the same Microsoft 365 / Outlook Tycoon 2FA lure, indicating broader infrastructure reuse beyond the initially observed .contractors clusters.

These domains exhibit the same execution flow, CAPTCHA gating, MFA-aware login sequence, and post-authentication behavior, confirming they are part of the same phishing operation, rather than unrelated or opportunistic reuse.

URLScan.io hash search

Note on Campaign Scale

The domains and infrastructure documented above represent only a subset of the total activity observed during this investigation. While many additional domains and variants were identified, listing all of them would significantly expand the scope of this post.

For the purposes of this write-up, I will leave the analysis here, focusing on representative samples that clearly demonstrate the campaign’s tradecraft and attribution.

Fake “PNB MetLife Payment Gateway” Page Stealing Customer Details and Redirecting Victims to UPI Payments

Anurag Gawande6 Comments

Overview

While actively hunting for phishing site, I came across multiple web pages impersonating PNB MetLife Insurance and presenting themselves as official policy premium payment gateways. This activity highlights how scammers deliberately target reputed and widely trusted brands to exploit existing customer trust and increase the likelihood of successful financial fraud. Although the pages claim to offer legitimate premium payment and policy servicing options, analysis of the underlying HTML and JavaScript shows that no real payment processing or backend validation is involved at any stage.

The pages are optimized for mobile devices, both in layout and interaction design. This strongly suggests that victims are likely being lured via SMS messages, although delivery via email, social media platforms, or messaging apps cannot be ruled out.

Fake PNB MetLife Payment Gateway – Initial Landing Page

The first template presents a mobile-friendly page branded as “PNB MetLife Payment Gateway”. It immediately prompts users to enter their name, policy number and mobile number, claiming these details are required to proceed with premium payment.

What is immediately noticeable is that the page does not validate any of the entered information. Any arbitrary values are accepted, and the user is allowed to proceed to the next step without verification.

hxxps://pnb-metlife-g-shiv-1aad8zgyup.edgeone.app/

Stealthy Data Exfiltration via Telegram Bots

Once the user submits the first form, the entered details are silently exfiltrated using the Telegram Bot API. Instead of communicating with a legitimate payment backend, the page sends captured information directly to Telegram, where it can be monitored in real time by the attacker.

The stolen data includes the victim’s name, policy number, and mobile number. Hardcoded Telegram bot tokens and chat IDs are embedded directly in the page’s JavaScript, leaving no ambiguity about the intent of the page.

During investigation, multiple Telegram bots and operator accounts were observed across related samples. Bots such as pnbmetlifesbot and goldenxspy_bot are used to collect victim data, while operator accounts including darkdevil_pnb and prabhatspy appear to receive and monitor these submissions.

Payment Amount Collection and Transition to UPI Flow

After the initial data theft, victims are taken to a second page asking them to enter the payment amount. Again, there is no backend validation or policy lookup. Any amount can be entered, and once submitted, this value is also sent to Telegram.

Immediately after this step, the page transitions into a UPI-based payment flow. The form disappears, and the victim is shown a QR code along with a countdown timer, creating urgency and psychological pressure.

QR Code Based UPI Payment Redirection

Once the victim submits the payment amount, the page dynamically switches to a QR based UPI payment flow. At this stage, no real payment gateway is involved. Instead, the JavaScript generates a UPI payment URI, renders it as a QR code, and pushes the victim toward completing the transaction inside a legitimate UPI app.

The following JavaScript snippet, extracted from the page, shows how the attacker generates the UPI QR code on the client side:

This code constructs a upi://pay URI and renders it as a QR code directly in the browser. Notably, the amount parameter is omitted or set to zero, forcing the victim to manually enter the amount in their UPI app.

Clipboard Abuse and Forced App Redirection

In addition to QR based payments, the page also includes direct buttons for PhonePe and Paytm. Clicking these buttons triggers JavaScript that silently copies the attacker controlled UPI ID to the clipboard and then redirects the victim to a payment app deep link.

The following snippet highlights this behavior:

This technique ensures that even if the victim does not scan the QR code, the UPI ID is already copied and ready to be pasted inside the payment app. Redirecting users into real UPI applications significantly lowers suspicion and increases the likelihood of successful fraud.

Second Phishing Template – Premium Update and Bank/Card Harvesting

In addition to the basic payment-only template, a more advanced variant was also observed. This second template follows a slightly different flow and is significantly more dangerous, as it escalates from payment fraud to full banking and card data theft.

The landing page again impersonates PNB MetLife and asks for name, policy number, and mobile number. After this, the victim is presented with multiple options such as Update Amount, Refund Your Amount, and Add AutoDebit System, creating the illusion of legitimate policy servicing.

hxxps://pnb-metlife-web-india-2025-pvt-xi0ogr8l7-2fhp3fxm5e.edgeone.app/

When the victim selects “Update Amount,” they are taken to a page prompting them to enter a new premium amount. After submitting the amount, the page displays a confirmation screen showing the entered policy number and amount, along with a button labeled “Complete Update.”

Bank and Card Details Harvesting

The next stage is where the attack becomes significantly more severe. The victim is presented with a Bank Details for Verification page.

The page claims this information is required for secure verification. Once submitted, all entered banking and card details are exfiltrated to Telegram using the goldenxspy_bot, with the data delivered to the Telegram user prabhatspy.

This confirms that the second template is not just payment fraud but a full scale financial credential harvesting operation.

Abuse of Free Hosting Platforms

Multiple variants of these phishing templates were observed hosted on EdgeOne Pages, which provides free hosting. This allows attackers to deploy and rotate phishing pages rapidly with minimal effort.

Across different deployments, the visual structure and JavaScript logic remain largely the same, while UPI IDs, mobile numbers, and Telegram bots change.

URLScan analysis shows multiple deployments of the same phishing kit, with identical client-side JavaScript logic and minor configuration changes such as UPI IDs, Telegram bots, and subdomain names.

https://urlscan.io/result/019bdbf6-dc98-7159-8a8b-45f4d97fe002/

https://urlscan.io/result/019bdabf-41f2-7613-81c0-1e99f27b3557/

https://urlscan.io/result/019bd9b5-431e-75b1-836b-ee5d50faaff0/

https://urlscan.io/result/019bd953-decb-72ae-aa3c-0693fdeac605/

https://urlscan.io/result/019bd950-f84f-718c-8b5e-b04f152e8898/

https://urlscan.io/result/019bd94d-3881-75ac-87ef-db3a317c8ff9/

https://urlscan.io/result/019bd5bb-d242-72bf-9f2f-52d5cab3894c/

https://urlscan.io/result/019b20cf-96e3-734b-bdb8-ef9aed13d27d/

https://urlscan.io/result/019b20cd-704f-763e-b7a7-67bccda9bda7/

User Advisory

Awareness and verification remain the most effective defenses against payment based phishing and fraud.