Matchube: Fake Sponsorships That Hijack YouTube

An email lands in a creator's inbox: Hollyland, the wireless-microphone brand every camera channel knows, wants to collaborate. A free Lark mic, an agreed fee, one 60-second video. The intermediary handling the deal is called Matchube, "the global infrastructure for creator sponsorships." The platform is beautiful: escrow-backed deals, $14.2M "paid to creators," logos of Spotify, Nike and Samsung. All you do is verify your channel with Google. Read-only, it says. Zero channel-management access, it says.

The owner of one 16-year-old channel reported losing it roughly two minutes after clicking that button. This post dissects the operation we call the Matchube campaign: a rotating network of at least twelve fake "creator sponsorship" platforms, one reusable kit whose "Sign in with Google" is an attacker-in-the-middle (AitM) reverse proxy of the real Google login, built to steal sessions rather than passwords, and an exfiltration pipeline to Telegram via a Cloudflare Worker. Three of its sites were still serving the kit when we checked on 30 September 2026.

Safety notice. Every indicator in this article is defanged (example[.]com). Do not visit the live domains. Nothing in our verification submitted any data to the operators; see Evidence and methodology.

At a glance

One victim, documented in real time

The clearest account comes from the owner of the MedellinStyle channel, who posted to Google's support community on 25 September 2026 after losing a 16-year-old channel. The chain they reported:

1. A sponsorship approach referencing Hollyland, routed through "Matchube."
2. The pitch page: joinmatchube[.]com/hollyland help, asking the creator to "Sign in with Google."
3. Within roughly two minutes of that sign-in, per the owner's report, an automated script changed the account password, removed the victim's passkey and enrolled an attacker-controlled passkey, and replaced both recovery phone and recovery email.

Two details make this case study material. First, if the account held a second factor, it did not help, because the attacker did not defeat Google's security; they inherited the victim's session (more below). Second, the report is corroborated: on r/YoutuberAdvice, a now-deleted post asking "Does anyone have experience with Hollyland or Matchube?" drew surviving comments from multiple creators describing the same email weeks earlier, one of whom replied to the pitch and stopped only at the "click the link" step. An Egyptian creator also posted a near-identical play-by-play on Facebook, including that Hollyland, contacted directly, told them it had no relationship with the intermediary.

The platform that isn't there

The Matchube site is the most convincing creator-economy fake we have dissected. It has the full SaaS vocabulary: escrow-backed deals, "instant CPM valuations," a partner program, case studies, an FAQ. The theatre is layered:

• Channel lookup: enter your handle, watch "Analyzing audience metrics… Evaluating 30-day view velocity & matching campaign budget…" (a progress animation, not analysis).
• Social proof: pre-seeded buttons for real, recognizable channels ("Sara Dietschy @saradietschy (932K subs)", "Tiff In Tech", "Justin Escalona") presented as platform users. There is no evidence those creators are involved; their names are scraped as bait, the same way the logo wall uses Nike and Spotify.
• Numbers: $14.2M+ paid out, 150K+ sponsor matches, 98.2% escrow success.
• Pre-emptive reassurance: an FAQ entry: "Is Google Sign-In safe for my channel? Yes. We utilize Google's official OAuth 2.0 protocol requesting read-only analytics data… We never see your password." Every word engineered to defeat the exact reflex that would save the victim.

It even ships the compliance props: links to Google's API Services User Data Policy, YouTube's terms, and a pointer to myaccount[.]google[.]com/permissions so victims can "verify" the connection afterwards. The kit's own HTML comments reference popka[.]js and telegram[.]js, the two scripts that do the real work.

The machine: a proxied Google login in a fake browser window

Here is what "Sign in with Google" actually does on Matchube. It does not use OAuth. The button is tagged data-popka="1", and popka[.]js responds to the click with a browser-in-the-browser (BitB) attack: it injects a counterfeit browser window, chosen per victim from four base64-encoded payloads (maclight, macdark, winlight, windark) to match OS and color scheme. The macOS versions draw traffic-light buttons and the Windows versions draw Windows controls; every version has a draggable title bar reading "Sign in - Google Accounts" and a fake URL bar with an SSL padlock showing accounts[.]google[.]com/v3/signin/….

Inside that window, the login form is the real accounts[.]google[.]com, transparently reverse-proxied through the phishing domain, an attacker-in-the-middle (AitM) design in the same class as Evilginx. popka[.]js proves it: an onmessage handler receives the proxied iframe's location and rewrites the fake URL bar live, replacing the campaign domain with accounts[.]google[.]com for display. The victim types their credentials, and any 2FA prompt, into the genuine Google page; the proxy in the middle records everything, including session cookies.

A per-victim tracking ID is minted on load (userid = btoa(host:random)) and becomes the path of that victim's proxied login session (/userid/<id>), so the operators can tell each capture apart.

The proxy architecture is visible across the whole domain. We requested 20 wildcard subdomains. Nineteen of them (login., www., app., auth., panel., dashboard., accounts., api. among them) served a reverse-proxy clone of vidooly[.]com, a real video-analytics company, while the twentieth, go[.]joinmatchube[.]com, proxied google[.]com itself, its responses even carrying google[.]com cookies. Any subdomain is a generic proxy; the phishing path is one route on the graph. This doubles as cloaking: scan login[.]joinmatchube[.]com and you find a benign analytics site.

The loot pipeline

telegram[.]js does the exfiltration. Read from the page source (never executed), its header comment is a gift:

// Hardcoded Cloudflare Worker URL (completely safe as it contains no secrets/tokens)
const WORKER_URL = 'https://young-union-ef00[.]mortoncharlie529[.]workers[.]dev/'

The script wraps window.fetch, intercepts the victim's login traffic, and relays it to that Cloudflare Worker (with a same-origin fallback at /api/index[.]php?action=telegram), which forwards to the operators' Telegram. Keeping the bot token server-side on the Worker, instead of pasting it into page config, is a real opsec upgrade over kits that leak their exfil credentials to anyone who reads the page.

Once credentials and cookies land, the takeover is mechanical. With the session inherited, the attacker rotates the password, swaps the passkey enrollment, and rewrites the recovery contacts, after which the original owner's every recovery path leads to the attacker. Hijacked channels are often repurposed or sold.

Twelve domains and counting

Certificate-transparency records and urlscan history map the build-out: one to three new "platform" brands per month since June 2026. The eight domains in the family with resolvable WHOIS records were all registered through Global Domain Group LLC; all are Cloudflare-fronted:

The last row deserves a pause: matchubee[.]com served the exact same 71 KB kit we captured on joinmatchube[.]com, then switched to unrelated promotional content within about half an hour of our first request. These domains are liquid assets, rotated or resold faster than blocklists can update.

The brand names follow one template: a friendly core (match, scout, cast) plus filler (join, go, in, it, app, ly), producing domains that read like product names rather than brands, so a creator glancing at the email sender sees nothing alarming. One adjacent anomaly we cannot attribute but flag for researchers: victims' emails referenced a "Forgelys" sender entity, and a similarly named forgelysys[.]com was registered 7 May 2026, three weeks before this wave began, but now serves unrelated content. Separately, note that Global Domain Group LLC also appears in an unrelated bank-giveaway phishing family we are tracking; that is a data point about where such campaigns shop, not evidence of a shared operator.

How to detect the next Matchube

The domains will be gone within weeks; the fingerprints survive rotation:

# Page-content fingerprints (passive crawl, benign GET):
- HTML referencing "/www/popka.js" and "/www/telegram.js"
- "const RDOMAIN = location.host" + base64 blobs decoding into
  #window / #url-bar / #ssl-padlock fake browser chrome
- Brand-slug path pattern (/hollyland) on a "creator platform" domain

# CT monitoring (weekly wildcard searches):
matchube   matchy   scouty   castly   zenxly   forgelys

# Exfil infrastructure to block/report:
young-union-ef00[.]mortoncharlie529[.]workers[.]dev   (Cloudflare Worker → Telegram)

# Behavioral rule for mail gateways:
cold sponsorship email + intermediary platform + "verify via Google" ==
  escalate before any click; verify the intermediary with the BRAND, not the platform.

The structural tell that survives everything: a sign-in window that cannot leave the page. Google's real sign-in either takes your tab to accounts[.]google[.]com or opens a genuine browser popup, a separate window you can drag outside the browser. A window trapped inside the page, drawing its own address bar and padlock, is the signature of a phishing page imitating browser chrome. If you are unsure about a URL, run it through a phishing URL checker first.

What creators, brands and platforms should do

For creators: sponsorship offers are bait you can verify in one step: email the brand through its official site and ask if the intermediary is real. Hollyland told the Egyptian creator, in effect, that it did not know them. That single check defeats the entire campaign. Never complete a sign-in in a window you cannot drag outside the page; if a deal dies without that step, the deal was the hook. And if you signed in: you have hours, not days. From a clean device, change the password, remove unknown passkeys and recovery contacts (check myaccount.google.com/security), revoke third-party access, and contact YouTube Partner support referencing channel hijacking. Afterward, treat any inbound message about your channel as possible social impersonation until you have verified it through official channels.

For brands (Hollyland et al.): your logo is the product being sold. Monitor for your name on freshly registered domains (this campaign adds the brand as a URL path, /hollyland, which is searchable), publish a "we only contact from @our-domain" page, and answer the verification emails creators send. One public denial kills a wave.

For Google and Cloudflare: the kit abuses both trust marks, Google's login chrome and Cloudflare's free CDN and Workers. The Worker exfil endpoint and the per-domain proxies are reportable infrastructure; reverse-proxied accounts[.]google[.]com served from a non-Google origin is a detectable pattern worth a content rule.

Frequently asked questions

Is "Sign in with Google" on a third-party site always dangerous?

No. Real OAuth is safe and common. The dangerous version draws a fake window inside the page, with its own address bar and padlock. A legitimate flow either takes your tab to accounts[.]google[.]com or opens a real browser window you can move outside the page, then asks you to grant named, revocable scopes.

How was the channel stolen if the victim had 2FA?

The kit reverse-proxies the real Google login, so it captures session cookies after authentication, not just the password. With a valid session, the attacker changes the password, replaces passkeys and recovery contacts, and locks the owner out. 2FA protects sign-in; it does not protect an already-established session handed to the attacker.

Why "Matchube"? Is it related to MatchHub, the Wimbledon ticket scam?

We named the campaign after its lead domain. A matchshub[.]com fake-Wimbledon-ticket scam reported on r/wimbledon in June 2025 predates it and uses a different kill chain (fake e-commerce via Facebook ads). The brandable "Match*" naming playbook rhymes, but we have not attributed the two to the same operators.

The site showed real creators as members. Were they involved?

No evidence of that. Recognizable channel names and subscriber counts are scraped as bait, the same way the logo wall uses Nike and Spotify without their knowledge.

Are the domains in this article safe to click for research?

No. The kit proxies live logins and logs everything. Use archived scans (urlscan[.]io) for verification and report rather than visit.

Download indicators

• Indicator inventory (CSV): 17 defanged indicators covering the twelve campaign domains, the exfiltration Worker, the two kit scripts, the /hollyland path pattern and the fake window title. Each row records its type, first-seen and last-verified dates, status, source and our confidence.

The status column is a snapshot from 30 September 2026. Domains in this family rotate quickly, so treat it as a record of what we saw that day rather than a current blocklist.

Evidence and methodology

All research was conducted passively or with benign, read-only requests on 30 September 2026, from a single research workstation.

• What we requested: single unauthenticated HTTPS GET requests for the campaign pages' HTML and the kit's JavaScript files (popka[.]js, telegram[.]js, both read, never executed); one GET per name across 20 *.joinmatchube[.]com subdomains to establish the proxy cloaking; DNS, WHOIS and certificate-transparency lookups (MerkleMap); urlscan[.]io search API queries; and read-only retrieval of community reports (Google support thread, Reddit, Facebook) in a sandboxed browser.
• What we did not do: we never entered credentials anywhere, never submitted any form, never completed any OAuth or popup flow, and never sent data to the exfiltration Worker. A single GET to the Worker returned 405 Method Not Allowed, which is consistent with the POST-only behavior declared in the kit's code; no POST was sent. No victim data was accessed, and none appears in this article. We note plainly that these GETs did contact the operators' infrastructure, including the Worker; we disclose this deliberately so the evidence chain is reproducible.
• Figures: Figure 1 is a live capture of the page as served. Figure 2 was produced by decoding the kit's own base64 window payload locally and rendering it in an isolated local browser context with no network access to campaign infrastructure; only the title bar and fake URL bar are shown.
• Sourcing: the takeover timeline (password, passkey, recovery changes within ~2 minutes) is the victim's report in the Google support thread, linked above. The Hollyland denial is second-hand, as reported by the Egyptian creator. The deleted Reddit post is cited only through its surviving comments. Domain ages come from CT logs and WHOIS; the zenxly[.]com CT date could not be resolved, so its first urlscan observation is used instead.

Authorship, review and corrections

This research post was produced by PhishEye Research. There was no independent technical review. Confidence levels are stated inline and in the indicators CSV accompanying this post: victim-reported events are attributed as such, and infrastructure findings are reproducible from the indicators list. Corrections or additional victims' reports are welcome via our contact page and will be appended with dates.

References

• Google YouTube support community thread 469967215: MedellinStyle hijack report, 25 Sep 2026 (domain, registrar, takeover timeline as reported by the victim)
• r/YoutuberAdvice thread (original post deleted; surviving comments confirm similar emails to multiple creators, ~Aug 2026)
• Public Facebook warning post by an Egyptian creator, 30 Sep 2026: full pitch-to-denial sequence, including the creator's account of Hollyland's denial
• r/wimbledon "MatchHub Scam" (June 2025): adjacent matchshub[.]com ticket-scam pattern
• urlscan[.]io scan history for the /hollyland family, Jun–Sep 2026; certificate-transparency records via MerkleMap for the domain table; full indicator list in the accompanying CSV