Yoroi Wallet Phishing Abuses GoTo Resolve and ScreenConnect for Device Takeover

Anurag GawandeLeave a comment

Overview

I recently came across a phishing campaign impersonating the Yoroi Desktop Wallet, targeting cryptocurrency users with what looked like a legitimate upgrade.

The email itself was clean and well-written. It talked about improved security, hardware wallet support, and even AI-based scam detection. Nothing immediately stood out as suspicious. The landing page looked polished too, with proper branding and a familiar layout.

The Setup

The phishing email redirects users to a domain:

hxxps://download[.]v1desktop-yoroiwallet[.]com/

the domain was recently registered (Feb 2026), yet it was already indexed on Google, meaning users could also land on it via search results, not just email.

The Download That Isn’t a Wallet

The site promotes a “Yoroi Desktop” download, but instead of hosting anything legitimate, it redirects to a file-sharing service and delivers an MSI file:

hxxps://store-na-phx-1.gofile.io/download/direct/900a7e14-a15a-41f6-94fb-c88603d09463/YoroiDesktop-installer.msi

hxxps://cold8[.]gofile[.]io/download/direct/900a7e14-a15a-41f6-94fb-c88603d09463/YoroiDesktop-installer.msi

hxxps://store-na-phx-5[.]gofile[.]io/download/direct/87c6015b-8a47-4cde-9e31-aaacd3f4193c/YoroiDesktop-installer.msi

Running the installer doesn’t give you a wallet. It installs GoTo Resolve (LogMeIn) in unattended mode.

Silent Remote Access via GoTo Resolve

File name: YoroiDesktop-installer.msi
File hash: 8634AD3C6488D6A27719C5341E91EEB9
File name: unattended-updater.exe
File hash: 2A2D9B03AA6185F434568F5F4C42BF49

Once executed, the system is quietly enrolled into a remote access setup. There’s no obvious warning, no suspicious pop-ups, just a legitimate tool being used in the wrong way.

Looking at the configuration reveals what’s happening behind the scenes:

CompanyId: 5504330483880245799
Namespace: syn-prd-ava-unattended
FleetTemplateName: syn-prd-ava-unattended

This isn’t random. It shows the machine is being registered into a pre-configured remote access fleet, controlled by whoever owns that GoTo Resolve tenant.

At this point, the attacker doesn’t need to trick the user anymore. They already have what they need, persistent access to the device.

A Second Variant: ScreenConnect

File hash: e79a47fc85955123f0821223a4cf2595
File name: yoroi-wallet.msi

While pivoting on this activity through URLScan, I came across another domain following the same theme:

yoroi-wallet[.]org

This one doesn’t use GoTo Resolve. Instead, it delivers a payload based on ConnectWise ScreenConnect, another legitimate remote access tool.

Inside the dropped configuration file, the intent becomes clear:

The important part here is the relay server:

instance-p1b26i-relay[.]screenconnect[.]com

This tells the client exactly where to connect. Once installed, the system reaches out to that server and establishes a remote session.

Again, no exploit, no malware in the traditional sense, just legitimate software used to gain control.

A Familiar Pattern

This isn’t the first time I’ve seen something like this.

It closely resembles a campaign I previously analyzed where RMM tools were abused in a crypto wallet distribution flow:

RMM Abuse in a Crypto Wallet Distribution Campaign

One thing that stands out across both campaigns is how the payload is delivered.

In all cases, the final MSI files are not hosted directly on the phishing domains. Instead, the sites redirect users to gofile[.]io, a legitimate file-sharing service, to download the installer.

This adds another layer of evasion. Hosting the MSI on a legitimate service like gofile makes it harder to block and also reduces suspicion from users, since the download doesn’t come directly from the phishing domain.

While digging further into this, I also noticed that the MSI files are hosted across multiple gofile storage endpoints such as:

store-na-phx-[1/4/5].gofile.io/download/direct/

Changing the server index (for example, 1, 4, or 5) reveals similar download paths hosting MSI files that follow the same theme, crypto wallet installers that actually deploy RMM tools.

Combined with the use of legitimate tools like GoTo Resolve (LogMeIn) and delivery through trusted file-sharing services, the overall chain appears clean on the surface but ultimately leads to full remote access.

Indicators

URLs

v1desktop-yoroiwallet[.]com
yoroi-wallet[.]org
instance-p1b26i-relay[.]screenconnect[.]com
YoroiDesktop-installer.msi
yoroi-wallet.msi
CompanyId: 5504330483880245799
Namespace: syn-prd-ava-unattended

File Hash

8634ad3c6488d6a27719c5341e91eeb9
2a2d9b03aa6185f434568f5f4c42bf49
e79a47fc85955123f0821223a4cf2595
be8c2d03333cbd13dab654260c60b025

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

Anurag Gawande1 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.