Fake Google Login Windows (Browser-in-the-Browser): Inside Two YouTube Phishing Kit Families

If a message says there is a problem with your YouTube channel — a copyright strike, a takedown, or a brand that wants to “collaborate” — and the link asks you to sign in with Google, stop. Both sites a reader asked us about use the same deception: a browser-in-the-browser (BitB) window — a fake “Sign in – Google Accounts” window, complete with title bar, padlock and an accounts.google.com address, drawn inside an ordinary webpage. This report explains how those copyright-themed pages imitate Google sign-in, how they disguise attacker-controlled frames, and how they use a channel’s public information to build trust. Following each site outward led to two observed families of phishing code: 224 hostnames in all, 26 of which reference the same Cloudflare Worker. We list every hostname with its evidence and confidence, and say plainly where our evidence stops.

Key findings

• It started with an e-mail that borrows YouTube’s own address. The copyright notice that began this investigation was sent through a newsletter service and linked to youtube.com/redirect?q=youtubeagency.help/…, so the visible link starts with YouTube’s real domain while the destination is the phishing site. Its wording — a formal notice, a case number, a one-day deadline, “three strikes” and channel termination — is built to make a channel owner act before checking.
• Both reader-named sites show a browser-in-the-browser window. youtubeagency[.]help draws the fake Google window with its own script (popka.js), loading the window’s content from its own host; on dmca-policy[.]com a live inspection found the Google-looking window inside an iframe served from a separate host, verify1you-be-main213047298[.]com. In both cases the accounts.google.com address is text on the page, not the browser’s address. The same technique on both sites does not show one operator, one developer, identical kits or a shared backend.
• 224 hostnames, 199 registrable domains in two observed code families, found from two domains a reader named, under the inclusion rules in “How we found them”. Confidence differs by group and is stated for every hostname. Before this work ScamMinder had analysed 4 of them (exact-hostname match, 2 November 2026).
• Family A — a browser-in-the-browser kit with authentication-proxy behaviour consistent with account-compromise phishing: 99 hostnames, of which 26 reference the same Cloudflare Worker in captured scripts (strong evidence of shared collection infrastructure, not proof of one person). We did not observe a completed authenticated session or directly verify session-cookie capture. 62 of the 99 resolve in DNS on 2 November 2026; October 2026 had the highest number of newly observed Family A hostnames in this dataset (23).
• Family B — a copyright-strike kit: 126 hostnames in four groups with different confidence. The React group (105 hostnames) is tied together by identical bundle files on 67 of them and identical logo and background images on all 105; 8 verification-gate hosts share one script (seven on a verify.* subdomain, one on ixmeraauth[.]io); 13 hostnames (an 11-host Cyrillic-title group and a 2-host plain-page group, which includes dmca-policy[.]com) are lower-confidence candidates linked mainly by lure similarity. 35 of the 126 resolve.
• The two domains the reader named: We found no evidence establishing common operation of youtubeagency[.]help and dmca-policy[.]com. Their captured pages use different code families. The available evidence does not establish whether their operators are the same, different, or otherwise connected. youtubeagency[.]help is in Family A; dmca-policy[.]com is in Family B’s lower-confidence plain-page group.
• One deployment loaded code from both families. On 22 July 2026 the captured page at youtube.copyright-status[.]click loaded the Family B bundle and a Family A script. That shows code co-presence on one deployment — nothing more.
• Every hostname, date, evidence type and confidence is in the tables below and in two downloadable CSV files: the 224-row host list and an evidence manifest naming the scan, URLs and artifacts behind each first and last observation.

The question we were asked

A reader pointed us at two live phishing sites, youtubeagency[.]help and dmca-policy[.]com, both posing as YouTube, and asked whether the same people run them.

We found no evidence establishing common operation of youtubeagency[.]help and dmca-policy[.]com. Their captured pages use different code families. The available evidence does not establish whether their operators are the same, different, or otherwise connected. What the two sites share is a story — “there is a problem with your channel, sign in to fix it”.

How the lure arrived: a copyright notice that borrows YouTube’s own link

The investigation began with this e-mail, received by a channel owner and shared with us. It is addressed to the person who runs a YouTube channel, and every element of it is chosen to make that person act quickly rather than check.

• A link that starts with youtube.com. The link is https://www.youtube.com/redirect?q=youtubeagency[.]help/?case=MC-4471. /redirect is YouTube’s own outbound-link endpoint — the one used when a link in a video description or comment points to another site — and the real destination sits in the q parameter. Anyone who hovers over the link, or whose mail filter checks only the domain, sees www.youtube.com; the browser ends up on the phishing site. YouTube may show its own “you are leaving YouTube” notice for such links; we did not follow this link, so we do not state what a recipient saw at that step. Either way, the address that matters is the one after q=.
• A real newsletter service as the sender. The message came from AlexReed@buttondown[.]email, signed “Copyright Notifications Dept.”, with a footer reading “This was issue #3 of You Channel” and Buttondown’s subscribe and unsubscribe links. Sending through an established newsletter platform lends the message that platform’s sending reputation and authentication; nothing in it comes from YouTube or Google.
• Fear and urgency. A “formal notification”, an “automated monitoring system”, a case reference, “exact timestamps of the flagged segments”, a deadline of “1 days”, a “formal copyright strike” and the reminder that “three active strikes lead to permanent channel termination”. The claim itself is vague — “proprietary software interface elements” — so that almost any channel could believe it applies.
• A case number the site does not use. The archived youtubeagency[.]help page does not read the case parameter at all: its own case label is built as DMCA- plus the current date (DMCA-20261102 in the screenshot below), so “MC-4471” exists only in the e-mail.

The same story — a copyright problem, a deadline, “sign in to resolve it” — is what both kit families in this report sell. The e-mail is the delivery; the browser-in-the-browser window is the trap it leads to.

Browser-in-the-Browser: the fake Google login window

The address shown inside a webpage is not necessarily the address of the document being loaded. These pages draw a browser-like window — a title bar, a padlock, Google branding and an accounts.google.com address — while loading the window’s content from attacker-controlled infrastructure. The real browser still shows the phishing site in its own address bar; the second “address bar” is part of the page.

Three different addresses are in play, and only the first one is vouched for by the browser:

1. The real top-level URL — what the browser’s own address bar shows (for example youtubeagency[.]help).
2. The document loaded inside the drawn window — an <iframe> whose source the page chooses (on youtubeagency[.]help, a path on the same phishing host; on dmca-policy[.]com, an external host).
3. The address text displayed by the phishing page — a string such as accounts.google.com/v3/signin/identifier?… painted onto the drawn bar.

Copying the displayed Google address therefore proves nothing: the copied string is simply text the page placed in its simulated address bar. A padlock drawn inside the page proves nothing about the connection either. The evidence that matters is the real top-level origin and the origins of the frames and requests.

BitB describes the deceptive interface. It does not by itself tell us what happens behind the window — whether the sign-in content is a static copy, a reverse proxy relaying the real Google pages, or something else. Below we keep three kinds of statement apart: what the source code says, what an archived or live browser actually did, and what remains unverified.

How we graded every link

Attribution is only as good as the evidence under it, so every connection is graded the way we graded our reused-infrastructure and illicit-shops reports. We use four evidence types, and none of them names a person on its own.

• Shared collection infrastructure — the same Cloudflare Worker or Telegram chat ID in captured scripts. Strong evidence that deployments feed one collection arrangement, and the basis for clustering them. It does not uniquely identify one person or crew: a shared service, a kit provider, an affiliate arrangement or a copied configuration remain possible. These values sit in client-side code, so they are not secrets.
• Shared code or assets — identical script, bundle or image hashes. This shows reuse; files can be copied, redistributed, leaked or built into another kit, so it does not identify a builder.
• Lure or title similarity — the same impersonated brand, title or story. This shows a shared lure, not a shared implementation, and is the weakest basis we use.
• Context — a shared Cloudflare address, a registrar or a name-server pair. Thousands of unrelated sites share these, and we never call an IP address or a registrar a “network”.

The two reader-named domains, side by side

Registrar and name-server values come from ScamMinder’s own evidence ledger. Sharing Cloudflare is not evidence of anything: a large share of unrelated sites sit behind the same provider. The two address rows come from different sources at different times and are not the same measurement.

Family A — a fake Google sign-in window with authentication-proxy behaviour

youtubeagency[.]help belongs to this family, which spans 99 hostnames and rotates between fake brand “collaborations” (Notion, N26, Burberry, Grammarly, Social Cat) and fake copyright desks such as “QayemDigital”. The captured material is consistent with account-compromise phishing; it does not show a stolen account. Below we separate what the archived browser received, what the scripts are programmed to do, and what we did not observe.

A script called popka.js paints a pixel-perfect fake “Sign in – Google” window (a browser-in-the-browser) whose address bar reads accounts.google.com; the window templates are embedded as base64 for macOS and Windows, light and dark. The scripts request an authentication path of the form /sign.do/<id>?continue=https://myaccount.<host>/…. In the A1 variants the script also posts, for the pages the visitor reaches, the page path, title, visible text and IP information to a Cloudflare Worker. The payload is formatted as a Telegram message with a chat ID, which suggests the Worker relays into a Telegram chat; we did not observe the chat itself.

What was observed, what the code is programmed to do, and what was not observed

• Requested and received in archived browsers. On inscouty[.]com (1 July 2026) the /sign.do/… request returned 200 text/html: a Google sign-in page titled “Anmelden – Google Konten” whose base address and links had been rewritten to inscouty[.]com, and a POST to the Worker returned 200. That supports a reverse-proxy reading. On youtubeagency[.]help (1 November 2026) the corresponding /sign.do/… request appears in the log but was aborted (net::ERR_ABORTED) with no response captured.
• Programmed in the scripts we read. Drawing the fake window; substituting the host name with accounts.google.com in displayed content; reporting page path, title, visible text and IP information to the Worker. We did not establish that keystrokes, passwords or backup codes are sent through that particular mechanism.
• What a server-side proxy could collect. A proxy sitting in the path can see whatever passes through it, but that happens on the operator’s server and cannot be observed from a client-side capture.
• Not observed. A completed authenticated session, the capture of authenticated session cookies, or a successful replay of a stolen session.

In short: Family A uses a browser-in-the-browser interface and authentication-proxy behaviour consistent with account-compromise phishing. Captured scripts report navigation and page information to a shared Worker. We did not observe a completed authenticated session or directly verify session-cookie capture.

Inside youtubeagency[.]help’s script: how the window is built

The archived seed scan (urlscan 01a198ac, 1 November 2026) served popka.js with SHA-256 8d30a5d6a78603e92fd438f4447805a9200049e8f81d262ef16093aa52235601 and a root page with SHA-256 e622808ddd750c4968d5919f99f9b826a9dddc4dd488006958367adf97f63474. We quote only the lines needed to explain the deception; we do not republish the kit.

The displayed address is a constant; the window’s real content is the phishing host. The script takes its host name from the page it runs on, fixes the window title and the displayed domain, and builds the iframe address separately on the same host:

const RDOMAIN = location.host;
const TITLE = "Sign in - Google Accounts";
const DOMAINNAME = "accounts.google.com";
const DOMAINPATH = "/v3/signin/identifier?continue=https%3A%2F%2Faccounts.google.com%2F…";
const WURL = `https://${RDOMAIN}/userid/${userid}`;

Four browser-window templates (macOS and Windows, light and dark) are embedded as base64 strings. Decoded, each contains the simulated title bar, window buttons, an SVG padlock (id="ssl-padlock"), the displayed address (id="domain-name", id="domain-path") and an <iframe id="content" src="$URL$">. When the window is shown, the script fills the placeholders: $DOMAINNAME$ and $DOMAINPATH$ become the Google-looking text on the bar, while $URL$ becomes WURL — a path on the phishing host itself. The iframe destination and the displayed address are independent.

The bar keeps lying as the window navigates. When the framed page reports its URL, the script rewrites the phishing host into Google’s before displaying it:

e.data.url = e.data.url
  .replaceAll(`myaccount.${RDOMAIN}`, "myaccount.google.com")
  .replaceAll(RDOMAIN, "accounts.google.com");
…
document.querySelector("#domain-name").innerText = url.hostname;
document.querySelector("#domain-path").innerText = url.pathname + url.search;

This is direct evidence of address-display spoofing in the captured implementation. It changes text inside the page; it does not and cannot modify the browser’s genuine address bar.

youtubeagency[.]help’s collection and telemetry paths

• An account-data forwarding handler. The archived root page contains a message listener that accepts messages of type === 'userinfo', serializes their contents and forwards them through send_telegram.php, under a notification heading that reads “GOOGLE ACCOUNT DATA RECEIVED”. The captured page contains an account-data forwarding handler. Visit-report payloads were captured; no account-data payload from the userinfo handler, credential submission or session-cookie transmission was observed, so we do not claim that any password, cookie or recovery code was transmitted.
• send_telegram.php also receives a visit notification (IP, country, operating system, browser, time) when the page loads.
• api.php receives tracking events: report_visit on load and report_success when the “sign in” button (#btn-modal-verify) is clicked. report_success is a click, not a successful sign-in or an account takeover — the name is the kit’s own.
• popka.js carries the shared Cloudflare Worker and Telegram chat ID discussed under A1, and posts navigation reports (path, title, visible text of the same-origin frame, IP) there.

In the archived scan the POSTs to api.php and send_telegram.php were later marked aborted. An HTTP 200 status from a notification endpoint would not show delivery to Telegram in any case. The root page also fetches public YouTube channel details (name, subscribers, videos) to personalise the lure; accurate channel branding is public information and is not evidence that the attacker already controls the account. The page embeds third-party API keys, which we do not reproduce.

A1 — shared Worker: 26 hostnames

All 26 A1 hostnames reference the same Cloudflare Worker, young-union-ef00.mortoncharlie529[.]workers.dev, in captured scripts: 21 in a captured popka.js and 10 in a captured telegram.js (five in both). 14 also specify one Telegram chat ID (−1003455815194) and 3 specify another (−1003798694171); 9 expose no chat ID in the captured file. This is strong evidence of shared collection infrastructure and supports clustering these deployments together. It does not, by itself, establish a single human operator. We use the term “chat ID” because the IDs alone do not tell us whether they identify groups or channels, who can read them, or whether messages were received.

A2 — popka.js lineage with a commented-out sweepinfluence.co line: 28 hostnames incl. the bridge

These hostnames serve popka.js variants that contain the line //const RDOMAIN = "sweepinfluence.co";. It is commented out: in three of the four variants we read, the active assignment is const RDOMAIN = location.host;, and the fourth contains only the commented-out line. We therefore present it as a historical code artifact, not an active destination. Lures include fake SM Entertainment, Anthem and Sony copyright appeals and Grammarly, Miro and G Fuel “collaborations”. Shared code shows reuse; it does not identify the builder or the operator. Earlier builds (A0, below) hard-code other RDOMAIN values.

A3 — QayemDigital lure with the shared popka.js: 2 hostnames

Two September 2026 hostnames show the same “QayemDigital” title as youtubeagency[.]help; one of them prints the address info@qayemdigital[.]com. Both also serve the same popka.js variant (sha256 d616c337…, served on 12 hostnames in all), which is what places them in Family A. The title is a lure, not an implementation, so we do not treat it as evidence of a shared builder: medium confidence, no more.

A4 — same template, no collection endpoint captured: 43 hostnames

These carry the identical browser-in-the-browser popka.js template but no collection endpoint we could read. They may be connected to the A1 deployments, to a customer of the same kit, or to someone who copied it; the evidence does not say which.

A0 — earlier builds, not counted in the 224

Seven hostnames from February–April 2026 carry earlier popka.js builds (different file hashes) with a different RDOMAIN: hard-coded in six, commented out in one. We list them as lineage evidence and leave them out of the counts because nothing links them to the counted cohort except the template itself — no shared endpoint, chat ID or identical file. Including them would add seven hostnames and move the counted cohort’s start from May back to February 2026.

Family B — a copyright-strike kit

Family B is a long-running copyright-strike kit across 126 hostnames in four groups. Its largest group, B1, is branded with a look-alike “Yоutubе | Copyright strikes” title that swaps Latin letters for Cyrillic look-alikes. Confidence differs sharply between groups, and dmca-policy[.]com sits in the weakest-linked one. The front-end domains look disposable: first observations span November 2025 to November 2026, and only 35 of the 126 hostnames resolve today.

The B1 bundle (read from its code) asks for your @channel to “review a claim”, calls its own /youtube-channel endpoint and shows the channel’s avatar, subscriber count and latest video. It then calls /get-active-domain, which is expected to return an “active verify URL”; the app tags it with a referral code, logs the visit and opens it. Separately, eight verification-gate hosts share the same _cf.js — seven use a verify.* subdomain, while one is ixmeraauth[.]io — and show a fake “verify you are human” check followed by “Verified — redirecting…”, and a script on those hosts (_cf.js) blanks the page and sends the visitor to youtube.com if it detects DevTools, a debugger pause or the view-source shortcuts. We did not capture a scan in which a B1 page navigates to one of those hosts, so linking the two rests on the bundle’s “verify URL” call and the shared naming, and we did not capture what comes after the gate, so we do not state what it asks for. Not every group uses the same endpoints: the Cyrillic group calls /api/knock and the plain group /api/notify.

dmca-policy[.]com is in B3. Its links are to dmca-claim[.]info only: a shared favicon and a code-level redirect (below); a raw urlscan search for that hash returns just those two hostnames, so it is distinctive within our data, but a favicon is a small file and an easy one to copy. Beyond it, the connection to the React group is a similar “copyright claim review” lure. Treat B3 as a lower-confidence candidate: no Telegram chat ID, Cloudflare Worker, or shared operator-linked collection destination was identified for it (its own /api/notify/… endpoints were seen).

dmca-policy[.]com: the verification frame chain (new evidence, 2 November 2026)

A new scan of the claim page (urlscan 01a19ae2, 2 November 2026, 06:12:11.961 UTC, dmca-policy[.]com/claim/CID-3LDWM, title “DMCA Claim Portal”) captured the scripts that open its verification window. /verify.js?v=2a01d844 has SHA-256 4eaccf03ee73bb84a2faacae1b357a7b28d955b5e43b440b95849964e314fa3b. The source code runs this sequence:

1. claim.js calls startVerify() when the visitor continues.
2. verify.js calls /api/notify/auth-start?id=<claim-id>.
3. Only after a successful response, openVerify() activates an overlay.
4. The overlay’s <iframe id="verifyFrame"> loads an external address.

frame.src = 'https://verify1you-be-main213047298[.]com/youtube/auth-verifi/?continue_verifi_userID_182iqqUTqwjRequestYoutube';

A later live browser inspection by our team reproduced the Google-looking window and recorded this DOM hierarchy:

• Top-level page: dmca-policy[.]com/claim/CID-3LDWM
• Outer iframe (#verifyFrame): verify1you-be-main213047298[.]com/youtube/auth-verifi/
• Nested iframe (#modalIframe): the same host at /youtube/signin/?step=login&sid=[REDACTED]&v=20261028e

The window visibly displayed accounts.google.com while the nested sign-in frame was configured on the external domain. None of the dmca-policy[.]com files we retrieved — the claim page, claim.js, verify.js — contains the text accounts.google.com or any browser-window markup, which indicates that the simulated window is drawn by the external framed document, not by dmca-policy[.]com itself. This advances the earlier report: the external destination had been identified, and now the BitB presentation and the non-Google frame sources have been reproduced in a live browser. We have not established the nested document’s backend behaviour, where any entered credentials would go, or whether session cookies are captured. Session-specific sid values are redacted.

How the copyright claim is constructed

claim.js (SHA-256 f8c193527bc6d867761f59a65dd176713db75468826b8892345fb93ba69c2751) builds the claim page in the browser:

• The rights-holder details — “Moodle Pty Ltd”, its e-mail and website — are hard-coded in the script. They are not evidence of any real complaint by that company.
• The strike number is computed: the script extracts the digits from the claim ID and adds 15620. CID-3LDWM therefore yields 15623, the number in the screenshot.
• The blurred “videos included in this request” cards are generated placeholders (maskedVideo()), not images of any disputed video.
• The “This is not my channel” button sends the visitor to dmca-claim[.]info. That is a direct code-level relationship between the two B3 sites, stronger than the shared favicon alone; it still does not establish common ownership.
• The channel name, avatar and counts come from the page’s own /api/claims/<id>/channel call — public channel information, not evidence of account access.

The only archived scan of verify1you-be-main213047298[.]com we located (17 October 2026, /youtube/main/) returned a 404 “Maintenance Underway” page behind Cloudflare. We did not locate an accessible archived capture of the auth-verifi or signin documents in the sources searched. We list this host as a newly identified dependency of dmca-policy[.]com; it is not added to the 224 counted hostnames, the tables or the CSV, because it is an authentication-stage host reached from a claim page rather than a host that matched the family inclusion rules.

B1 — React group (104 listed here, plus the code co-presence host in A2)

B2 — Cyrillic (11) · B3 — plain (2) · B4 — verify gate (8)

The B1 table lists 104 hostnames; the 105th React-group host is the code co-presence host, listed in A2 above. Subdomains with random prefixes (for example 1t., 4x.) are separate hostnames of the same registrable domain, which is why 126 hostnames map to fewer registrable domains. “urlscan (first)” links the scan behind the first observation; the evidence manifest lists the last one too.

The one deployment that loaded code from both families

On 22 July 2026 the captured page at youtube.copyright-status[.]click loaded artifacts associated with both families: Family B’s React bundle and stylesheet (identical to the files on the other B1 hosts) and a Family A popka.js variant. This demonstrates code co-presence on that deployment. It does not identify the developer, establish common operation of the wider clusters, or explain how the components were combined. The popka.js there carries the same commented-out sweepinfluence.co line described in A2 — a historical artifact, not an active destination. Nothing about this host changes our answer on the two reader-named domains.

When hostnames were first observed

Counts are hostnames first observed in the collected urlscan dataset; they are lower bounds on observed deployments under the inclusion rules, not counts of operators, victims or measured activity. October had the highest number of newly observed Family A hostnames: 23, 16 of them referencing the shared Worker. For Family B, first observations were highest in April and May 2026 — 28 and 51 across all groups (24 and 45 for the React group alone) — and low from July. The counted Family A cohort begins in May 2026; related earlier builds are listed separately as A0.

Indicators

Shared collection infrastructure (clustering evidence, not identity)

Family A script variants (SHA-256 of the served file)

Thirteen telegram.js variants were served on the hostnames in this report (38 hostnames in all; no hostname served more than one variant). Only one of them carries the Worker: 7c3048746bc615fbceecae4455fd00cb241b54a77ba351d85966ed78d947a676, on 10 hostnames (all in A1). The other twelve do not contain the Worker: 575a5189eb85479fa47efb489d999cfe4a0f6deca431a02afcb882f7f0ffce74 (7 hostnames); e2828accb0a0d59d43f571a9a460d3c588b56eb53663e98b84a00c78164ba25d (6 hostnames); 1c8d7ed7c5f7505a8afcc78d147fdee60b164901b2b822f9b944684e41d54062 (5 hostnames); fa9fb5ea754c1a01b10967fbcde00dc9965d39a73548aa2130173b69fbec0fbe (2 hostnames); 1ce4df75abb3d1c0e854169ce4270c8d7ec32c03d6358f10db539b122b4f537f (1 hostname); 17132df7f320ebc348e56645bcf42134171e3945ec623b16e1ebcd88fedf352f (1 hostname); dbeb8552073c9e377855d79fb90a886027ad8a5663f7d44424b4e73bc60cc580 (1 hostname); 9d33214040b921a3acc1f7927389e7324bab0b889e207ad79b6a6732e77c979d (1 hostname); 494316d4f02b65d775a5af5c287b72db7e3bf1cd1dca2f7bab0b3bfc7cdef7b5 (1 hostname); b885ba81635def7899897baeaee1ec660b1e65cd1389b41ff596e513b40f76de (1 hostname); 0809af05191407e98ce3a6fe1b557e8eaeac6e7a90ddb2930324a48224f64334 (1 hostname); 99f65ee3ed87d14f82bb00462592194f154cf1cd3a29860e40b144fe7f1db7e2 (1 hostname). Many unrelated pages also use the file name telegram.js; only hashes found on the hostnames above are counted.

Family B assets (SHA-256)

“Raw urlscan matches” is every hostname urlscan returned for the hash; it is not a membership count. Only the hostnames in the fourth column are in this report, and the two files marked “not used” were not used to add any hostname. Generic responses shared by unrelated sites — {"ok":true}, "Not found!", Google font files and the empty-file hash — were excluded as non-evidence.

What ScamMinder had already seen

We checked each of the 224 hostnames against ScamMinder’s database on 2 November 2026 at 05:51 UTC, matching the exact hostname against stored websites with or without a scheme or path. Four matched: dmca-policy[.]com (warning / 28), youtubeagency[.]help (warning / 8), dmca-desk[.]com (inactive) and balancealign[.]live (scam / 25 — it earlier served a crypto page). A fifth hostname, ye.dmca-desk[.]com, shares a registrable domain with the dmca-desk[.]com record but is not itself an analysed record. The other 219 had no exact match. Scores are as of that check; two of the records were re-analysed after our first look.

What we cannot say

• We found no evidence establishing common operation of youtubeagency[.]help and dmca-policy[.]com. Their captured pages use different code families. The available evidence does not establish whether their operators are the same, different, or otherwise connected.
• The same technique is not the same actor. Browser-in-the-browser windows on both seed sites do not establish one operator, one developer, identical kits or a shared backend — youtubeagency[.]help draws its window with its own popka.js, while on dmca-policy[.]com the window comes from an external frame we could not archive.
• Shared collection infrastructure is not an identity. The shared Worker and Telegram chat IDs support clustering the 26 A1 deployments together; they do not establish a single person or crew. Everything else here is shared code, lure similarity or context, which shows reuse, not who used it.
• We did not observe account theft. No completed authenticated session, session-cookie capture or replay was observed, and the scripts we read report page path, title, visible text and IP information — not necessarily keystrokes or codes.
• DNS results are point-in-time and typed. “Resolves” means an address record came back from 1.1.1.1 on 2 November 2026; it is not “live phishing”, because parked and suspended pages still resolve. NXDOMAIN means the resolver reported the name as nonexistent at that time; it does not establish expiry, permanent removal or a takedown. SERVFAIL and names with no address record are counted separately.
• We do not know what Family B asks for after the human-check gate, and we did not observe the hand-off from the React group to that gate.
• Dates are first and last observations in the collected urlscan dataset, not registration, activity or takedown dates, and coverage is partial, so every count is a lower bound.
• 9 of the 26 A1 hostnames print no chat ID in the file we captured; they are in A1 because they reference the same Worker.

Technical evidence table: scripts, hashes and limits

Open research questions

• The external verification component. Its HTML, CSS and JavaScript — the files that draw the simulated bar and the nested login — were not found in an accessible archived capture in the sources searched; the only capture of the host we located is a 404 page. Open.
• Static clone or proxy? Not determined for dmca-policy[.]com’s chain. For Family A, a proxy-style response is shown on inscouty[.]com only.
• Form destinations and message handlers. For youtubeagency[.]help they are listed above. For the external frame they are unknown; we did not submit any data, real or synthetic, and did not complete any sign-in.
• Cookie or session capture. No evidence on either site. The limitation stands.
• Common artifacts. Beyond the technique, we found no distinctive artifact shared by youtubeagency[.]help, dmca-policy[.]com and the external host; generic Google branding and Cloudflare hosting do not count.
• Debugger pauses. No debugger statement or DevTools detection appears in any seed-site file we retrieved. The anti-analysis script _cf.js was observed only on the eight B4 verification-gate hosts. The source of the pauses reported on the seed sites is unidentified, so we make no anti-analysis claim about them.
• Different content for different visitors. One direct collection of dmca-policy[.]com returned an unrelated article page (a “PlatformWatch” article) while other captures returned the claim portal (and earlier captures carried a Spanish title). What decides which version a visitor gets is unknown.

How we found them

Starting from the two reader-named domains we ran unlisted urlscan.io scans, read the served scripts, and pivoted on features a kit repeats or an operator sets: the file names popka.js and send_telegram.php; the endpoint names /api/knock and /api/notify/visit; the page titles “QayemDigital” and “Copyright strikes”; the full SHA-256 of each distinct script, stylesheet and image above; and the Worker and Telegram identifiers once read. Inclusion rules. Family A: a captured popka.js of the template described above, or the shared Worker. Family B: the React bundle or its logo/background images (B1), the identical _cf.js (B4), or — at lower confidence — the Cyrillic-title or plain-page pattern (B2, B3). Each candidate was checked against the captured page, and a hostname’s dates and scan IDs come only from scans whose final page URL has that exact hostname (the evidence manifest lists them). Bot tokens and chat IDs that belonged to unrelated phishing pages returned by the same filename search were discarded. DNS was queried with dig against 1.1.1.1 for A and AAAA records on 2 November 2026 at 05:46 UTC, recording NOERROR, NXDOMAIN, SERVFAIL and timeouts separately; an earlier 1 November check through the system resolver did not distinguish those outcomes and was replaced.

urlscan.io is used here for research only; ScamMinder’s product does not use it.

How to protect your channel

• YouTube sends legitimate copyright-strike notifications by email. Verify the issue by opening YouTube Studio yourself, from a trusted bookmark or an address you type. Do not enter credentials into a page just because a message describes a copyright problem.
• A link that starts with youtube.com is not proof it stays on YouTube. In a youtube.com/redirect?q=… link the destination is the address after q=. Do not follow links in a copyright e-mail at all; open YouTube Studio yourself.
• Verify sponsorship requests through an independently obtained company contact. A Google sign-in prompt alone does not make a request legitimate or fraudulent: check the real browser origin and review any account permissions you are asked to grant. See also YouTube’s creator safety guidance.
• Read the real address bar, not the one drawn inside the page. A padlock or an accounts.google.com address drawn inside a webpage proves nothing about the connection, and copying that address only copies text. What counts is the real top-level origin in your browser’s own bar. The simplest response to a suspicious sign-in window is to close the page and open the service yourself. (A drawn window usually cannot be dragged outside the tab, but treat that as an illustration, not a safety test.)
• Use passkeys or a hardware security key. They are bound to the real sign-in origin, so they protect against deceptive-origin authentication; they do not eliminate risks from malware or from sessions that were already stolen.

If you entered anything

1. Start with Google and YouTube’s own guidance: recover a hacked YouTube channel.
2. Use a device you trust to secure or recover the Google Account. Review signed-in devices and sessions and sign out of any you do not recognise.
3. Remove unfamiliar third-party access, then inspect the recovery email, phone and two-step settings for changes you did not make.
4. If backup codes may have been exposed, generate a new set. If you downloaded or ran any software, scan that device.
5. Review your YouTube channel’s managers and permissions. Changing the password alone is not a complete recovery.

You can check a suspect link on ScamMinder before you click, and our Get Help desk can walk you through next steps after you have started the official recovery.

For abuse and takedown teams

The most useful single reports are the sending newsletter account (to Buttondown), the Worker (to Cloudflare), the two Telegram chat IDs (to Telegram) and the A1 hostnames that still resolve. The CSV lists every hostname with its group, evidence type, confidence and dates.

Follow-up captures after the dataset cutoff

The hostname dataset retains its observation cutoff of 1 November 2026. The 2 November follow-up captures are documented separately and are not incorporated into the CSV’s last-seen fields.

Downloads and evidence

Download all 224 hostnames (CSV) — columns: host, code family, group, evidence type, confidence, basis, first and last seen, first and last observation scan IDs, DNS result and addresses on 2 November 2026, Telegram chat ID, popka.js SHA-256, ScamMinder record. Download the evidence manifest (CSV) — for each first and last observation: the urlscan ID, scan time, submitted URL, final page URL, the role of the listed hostname (always the page host) and the artifacts seen. Hostnames in the CSV files are not defanged; do not open them. Both files still describe the 224 counted hostnames; the newly identified dependency verify1you-be-main213047298[.]com is listed in this article, not in the CSV.

Change log

• 2 November 2026 — browser-in-the-browser update. Added: the BitB explanation and Figure 7; source-code analysis of youtubeagency[.]help’s popka.js and root page (window templates, displayed versus loaded address, account-data handler, telemetry events); the dmca-policy[.]com verification frame chain from a new scan and a live inspection; how its claim page is constructed; two screenshots supplied to ScamMinder plus annotated copies; a technical evidence table and open research questions; new title, cover illustration and metadata. Unchanged: the 224 counted hostnames and their dates.
• 2 November 2026 — the lure e-mail. Added the copyright-notice e-mail that started the investigation: its youtube.com/redirect link, the newsletter-service sender, the fear-and-urgency wording, and the fact that the site ignores the e-mail’s case number.
• 2 November 2026 — precision corrections. The cover no longer implies that every hostname shows a BitB window; the eight verification-gate hosts are described as seven verify.* subdomains plus ixmeraauth[.]io; the dataset cutoff of 1 November is stated and the follow-up captures are listed separately; the payload statement now separates the captured visit reports from the unobserved account data; archive statements are limited to the sources searched; the CSV group A1 operator core is renamed A1 shared collection infrastructure; Figure 7 re-laid out; an annotated copy of the dmca-policy[.]com screenshot added.
• 2 November 2026 — evidence review. Attribution wording narrowed to what the evidence supports; confidence stated per hostname; DNS re-measured; two date and scan-ID provenance errors corrected; Figure 2 redrawn for all Family B groups; an evidence manifest added.
• 1 November 2026. First publication.

Window: October 2025 – November 2026. Unit: hostnames unless a registrable-domain count is stated. Hostnames are defanged in this article and none links to a live phishing page.