share.google Phishing: How a Google Link Hid a Netflix Scam

TL;DR — A Netflix "Payment Unsuccessful" email carried a link on share.google, Google's own link shortener. Following it, share.google hands off to www.google.com/share.google?q=…, and Google's front-end server (server: gws) answers with a 301 straight to login-netflix.renew-service01373[.]org, a phishing host behind Cloudflare. The redirect is marked cacheable for 30 days. The only domain in the payment link belongs to Google. The attacker's domain only appears once the click is already under way. On the far side sits a fingerprinting gate that hands each visitor a fresh URL, a random page body and an encrypted bot check before it shows anything. Scanners got an "IP must be allowed" message or a Cloudflare error. We found a second share.google link and two sibling domains (.net and .com) registered the same day. The .com is live with the same kit. On 30 October 2026 Google's Transparency Report flagged both live registrable domains as unsafe, yet both share.google links were still redirecting.

About this analysis. A reader sent us a screenshot of the email and the link from it. On 30 October 2026 PhishEye followed the chain with read-only HTTP requests: response headers for the two Google hops, and the HTML of the first two attacker pages, saved as text. We did not run the attacker's scripts, pass the gate, submit any data or view the final page. We describe the gate from its readable strings and visible code, not from running it. We did not receive the original .eml, so the sender, authentication results and mail route are not analysed. Indicators are defanged. Domain, certificate, DNS and Safe Browsing details come from RDAP, Certificate Transparency, public DNS, Google's Transparency Report and public urlscan.io records, all checked on the same day.

Safety notice. Do not visit the URLs below, and do not enter anything into them.

hxxps://share[.]google/psORhqxHbMVV9JiVQ
hxxps://www.google[.]com/share.google?q=psORhqxHbMVV9JiVQ
hxxps://login-netflix.renew-service01373[.]org/index.html

Key findings

• Google issues the redirect, not a third party. The first two hops are answered by Google's own servers. The attacker's hostname is not in the link at all. It exists only in the Location header of a 301 from www.google.com.
• The redirect is cacheable for 30 days. Google's 301 carries cache-control: public, max-age=2592000. A browser that has followed the link once can keep sending its user to the phishing host without asking Google again, even after Google disables the link.
• Safe Browsing knows the domains, but the redirect still works. When we checked on 30 October, Google's Transparency Report said "Some pages on this site are unsafe" for both renew-service01373.org and renew-service01373.com. The exact phishing hosts showed "No unsafe content found", and both share.google links were still answering with a 301.
• The kit is built to defeat scanners. Every visit gets a new path and a new random string in the page, so no two responses hash the same. A fingerprint check then posts an AES-encrypted report back to the server before anything else loads. urlscan.io's scanner was told "Your IP address (…) must be allowed before access."
• It is a set, not a one-off. Three renew-service01373 domains were registered the same day. A second share.google link, scanned publicly on 28 October, points to the .com, which serves the same kit today.

The email: an ordinary Netflix billing lure

Nothing in the message itself is new. It uses Netflix's red and white, a "Membership Information" banner, and the familiar story: the automatic payment failed, the card was declined or has expired, update it to keep watching. The tells are the usual ones. The greeting is "Dear costumer", it is not addressed to anyone by name, and it is signed "Team Service". Netflix says plainly that it will never ask you to share personal information in a text or email, and that includes card numbers.

The interesting part is not the text but the button. In this campaign it is a Google link.

What share.google is

share.google is a link shortener that Google runs for its own apps. When someone shares a web page they opened from Google Search or Discover in the Google app, the app can replace the page's real address with a short share.google/… link. 9to5Google reported the rollout in June 2025, including a "Shorten links to web pages" setting that is on by default. Android Authority had spotted in April 2025 that Discover shares were already swapping site URLs for search.app and share.google links.

Two properties make the service attractive to a phisher:

1. The domain is Google's. share.google and google.com sit at the top of every reputation list. Few organisations would ever block them, and many allow-list them outright.
2. The destination is not in the link. A share.google ID is opaque. Nothing in psORhqxHbMVV9JiVQ tells a filter, or a person hovering over the button, where it goes. You only find out by asking Google.

The link in this email takes the slightly longer form www.google.com/share.google?q=<ID>. Google does not document this form. Sublime Security's detection rule for it notes that it lets an attacker "inherit google.<tld> domain reputation" for a destination it hides.

We do not know how the operator created these two IDs. Whatever the route, the result is the same. On 30 October, Google's own front end was serving a permanent redirect to a phishing host on a domain that Google's own Safe Browsing data flags as unsafe.

The redirect chain, hop by hop

Two details in hops 1 and 2 matter more than they look.

The first is who answers. A filter that follows redirects at delivery time sees two responses from Google and no page content at all. A filter that does not follow redirects sees only share.google. Either way, the first attacker-controlled byte only appears once the link has been followed.

The second is the cache header. 301 means "moved permanently", and Google adds an explicit public lifetime of 30 days. Browsers keep permanent redirects, so a person who clicked once, closed the tab and clicked again later may never touch Google the second time. If Google disables the ID tomorrow, that person's browser can still remember where it pointed.

Why it gets past the filters

People describe this kind of link as "bypassing everything". That overstates it, but not by much. Here is what each common control actually sees.

The common thread is that each control checks the one layer it is good at, and this chain puts something trustworthy in exactly that layer. The reputation check gets Google. The scanner gets a gate. The CT monitor gets a wildcard. The human gets google.com.

This is the same shape we described in the phishing page brand tools cannot find. There, the brand also sat only in a subdomain behind a wildcard certificate, and four standard discovery channels missed it for four different reasons. The share.google hop adds one more layer in front.

Inside the gate

The page at hop 4 is small and does one job: decide whether the visitor is a person worth phishing. From its readable strings and visible code:

• A trap link for crawlers. The page has an empty, invisible link to ./blackhole\. People never click an empty link. A crawler that requests every href does, which tells the server that the visitor is a bot.
• A browser fingerprint. Fields named fpw1, fpw2, fpnv and fpdv sit next to calls such as getOwnPropertyNames and getComputedStyle. This is consistent with fingerprinting the window object, the navigator and a styled element, then hashing each result with MD5. The script also records how many scripts the page holds and the referrer.
• A check for tampering. The string table contains [native code] and fields named injfn and injfnlst. Testing whether built-in functions still report [native code] is a standard way to spot functions replaced by automation tools and analysis hooks.
• An encrypted verdict. The collected data is serialised to JSON and encrypted with AES in CBC mode using CryptoJS 4.1.1, loaded from cdnjs. It is sent by fetch as a POST to ./index.php?gsauth, after the script clears the browser console. If the server answers OK, the page reloads its own URL, and only then does the server return the next stage.

Around the gate, the kit adds two more layers of noise. The first page differs on every request, with a new 7-character string in a hidden heading and a new path suffix, so a hash of the response is worthless as an indicator. And on both live domains, any hostname other than login-netflix resolves, thanks to wildcard DNS, but returns a generic 404. Probing random subdomains turns up nothing.

The response headers point to later stages we did not see. Each attacker response carries a Content-Security-Policy-Report-Only header whose connect-src list names *.ipify.org (a public IP lookup API), *.hcaptcha.com, *.awswaf.com, and websocket endpoints under *.dns.navy. Its report-uri points back to the kit at /misc/index.php?csp_rpt=<hex>. A report-only policy blocks nothing; it only reports. We read that list as a map of what the next stages connect to: an IP lookup, a CAPTCHA, and a live socket of the kind used to relay victims to an operator panel. That is an inference from the header, not something we observed.

The Outlook phishing chain we analysed in September used a similar split. A basic HTTP client got a Bing diversion there, and only a browser that passed a local check reached the credential page.

Three domains, one odd string

The name renew-service01373 is distinctive enough to search Certificate Transparency for it. It exists in three TLDs, all registered the same day through the same registrar with the same set of locks.

Every certificate on all three domains is a Cloudflare-issued wildcard for *.renew-service01373.<tld> plus the apex. The .org certificate has been renewed several times since June, most recently on 18 October. The .com sits on a different Cloudflare nameserver pair, and its registration record was last changed on 18 August, the day its first certificate was issued. All three carry the same four registrar locks: clientDeleteProhibited, clientRenewProhibited, clientTransferProhibited and clientUpdateProhibited.

The .com serves the same first-stage stub as the .org: a random hidden heading and a script redirect. It sends the same CSP header but uses its own path prefix, which also changes over time: HR7L3DgE-xcpkeyLc-HA9767x-… on our visit, v3Tw35h-m2ar1a-XwLs2msy-… in urlscan's scans on 27–28 October.

A second share.google link

Public urlscan.io records show a different short link, share[.]google/dWBzLFgpysLABjnSI, submitted on 28 October 2026. When we followed it on 30 October, Google still answered:

GET  https://www.google.com/share.google?q=dWBzLFgpysLABjnSI
HTTP/2 301
location: https://login-netflix.renew-service01373[.]com/index.html?shem=aimgspe,
cache-control: public, max-age=2592000

So the operator rotates both layers: more than one Google short link, and more than one domain behind them. The shem=aimgspe, parameter is appended by Google's redirect, not by the attacker. We have not found documentation of what it encodes. urlscan's three public scans of the .com ended in Cloudflare 520 errors or the IP allow-list message, never the payment page.

Part of a long run of Google redirect abuse

share.google is the newest member of a family that defenders have been writing about for years.

• Integrity360's SOC published an analysis of phishing campaigns abusing Google redirects in February 2026. It names share.google alongside google.com/url, google.sm, AMP, Google Translate and Google Maps. It also notes that the final destination changed with the user agent and context, with sandboxes sometimes landing on benign sites while real users reached phishing pages.
• Hornetsecurity's Threat Intelligence Lab documented a multi-layer open redirect chain through Google Meet in March 2026, nesting meet.google.com/linkredirect, google.com/url and an AMP path before the phishing page.
• SANS Internet Storm Center handler Jan Kopriva showed in May 2025 that google.com/travel/clk tokens could be reused to send people anywhere, including tokens that had already appeared in earlier phishing. He also challenged Google's position that well-monitored redirectors pose "very little practical risk".
• Sublime Security ships detection rules for this exact form in message bodies and in attachments, tagged as credential phishing via open redirect.

Google's Bug Hunters guidance on open redirectors says a report of an open redirector alone will not get a bug filed. It argues that a small number of "properly monitored" redirectors pose "very little practical risk", and that Google invests in detecting phishing instead. The monitoring is the part this chain tests. The destination's registrable domain was already flagged in Google's own Safe Browsing data, and Google's redirect kept sending people there.

It also fits our own numbers. In Where Phishing Lives in 2026, Google's free services hosted more of the platform-based phishing in our data than Cloudflare's. That study counted pages hosted on Google. A share.google link hosts nothing, which means it shows up in no hosting count at all, while still lending Google's name to the click. In our 2026 phishing statistics report, one documented calendar-invite chain likewise passed through a high-reputation Google tracking URL before an open redirect.

How to detect and block share.google phishing

Email and web security teams

• Treat Google short links in inbound mail as unknown, not trusted. Flag share.google/… and google.<tld>/share.google?q=… in messages from external senders, especially next to billing, account or delivery language. Sublime's rule logic is a good model: domain SLD google, path starting /share.google, and a q parameter.
• Resolve the whole chain at click time. Score the final destination, not the first hop. A trusted domain that redirects to a newly registered domain is a strong signal on its own.
• Run JavaScript when you resolve. The first attacker page is a 219-byte script redirect. A resolver that stops at HTTP redirects reports an empty page.
• Do not rely on one-shot scans. This kit tells scanners to go away. A scan that comes back empty or with an error is not a clean verdict.
• Block the indicators below, and consider blocking the whole renew-service01373 set across TLDs.

Hunters and brand teams

• Hunt on the kit, not the hostname. Durable strings include the CSP report-only header with wss://*.dns.navy:* and /misc/index.php?csp_rpt=, the index.php?gsauth endpoint, the hidden inputs id_gs_step and id_gs_token, and the stub pattern of a hidden <h1> with seven random characters followed by window.onload → /<prefix>-<7 chars>/index.html.
• Watch DNS, not only certificates. The brand never reaches a CT log here. It does reach DNS, because login-netflix is a real hostname that resolves. Our brand protection monitoring combines DNS, certificate and page-content signals for this reason.
• Pivot on the registrant pattern. Same-day registrations across .org, .net and .com with an unusual numeric string are a pattern worth alerting on in newly registered domain feeds.

Everyone else

• A Google link is not proof of a Google destination. share.google can send you anywhere.
• Go to the service directly. If Netflix, or anyone else, says your payment failed, open the app or type netflix.com yourself. Do not use the button.
• Report it. Forward Netflix phishing to [email protected], as Netflix asks. If you are unsure about a link, our free phishing URL checker and email header analyzer can help.

How to report and take it down

This chain has four parties that can break it, and the fastest takedowns work on several at once.

Killing the domains removes every short link that points at them. Killing the short links protects anyone who has not clicked yet, but the 30-day cache means some browsers will remember the destination anyway. That is one more reason to go after the domain too. Our guide to taking down a phishing website covers the evidence each party needs. Our phishing takedown service files and chases the reports for you, and How Fast Do Phishing Sites Come Down? shows what to expect once they are in.

Indicators of compromise (IoCs)

All indicators are defanged. Collected 30 October 2026.

MITRE ATT&CK mapping

How PhishEye helps

PhishEye watches for brand impersonation across DNS, Certificate Transparency and page content, which is what catches a login-netflix hostname that never appears in a certificate. When we find one, we file and follow the takedown with the registrar, the host and the platform in front of it. See phishing and scam protection and phishing takedown.

Frequently asked questions

What is share.google? share.google is Google's own link shortener for its apps. When you share a page opened from Google Search or Discover in the Google app, it can replace the real address with a short share.google/… link. Opening that link makes Google redirect you to the original page.

Is share.google safe? share.google is a real Google domain, but a share.google link can point anywhere, including a phishing page. In this campaign, two share.google links redirected to a Netflix phishing kit. A link you created yourself from the Google app is fine. Treat one that arrives in an unexpected email or text the way you would treat any short link: as unknown until you know where it goes, and never sign in or pay after following it.

How does a share.google link get past email security? Filters judge links largely by domain reputation, and the only domains in the link are Google's. The attacker's domain only appears in the redirect Google sends after the click. Behind that, the kit blocks scanners with a fingerprint gate, so sandboxes see an error or an "IP must be allowed" message instead of the phishing page.

Did Google's Safe Browsing flag these phishing domains? Partly. On 30 October 2026, Google's Transparency Report said "Some pages on this site are unsafe" for renew-service01373.org and renew-service01373.com, but "No unsafe content found" for the exact login-netflix hosts. Both share.google links were still redirecting that day.

How do I check where a share.google link goes without opening it? Ask your security team to resolve it in a sandbox, or use a link-expansion tool that shows the redirect target without loading the page. Expect the destination to change with your browser and location, and do not treat a clean result from a scanner as proof of safety.

I clicked the link and entered my card. What should I do? Call your bank or card issuer and cancel the card. Change your Netflix password and the password on any account that shares it, sign out of all devices from Netflix's account settings, and watch your statements. Forward the email to [email protected].

Who do I report share.google phishing to? Report the short link and the final page to Google through its Safe Browsing phishing report, the domain to its registrar's abuse address (for these domains, [email protected]), and Netflix-themed lures to [email protected].

References

• Integrity360 SOC — Abuse of Google redirects in phishing campaigns (February 2026)

• Hornetsecurity — Multi-layer open redirect abuse leveraging Google Meet (March 2026)

• SANS Internet Storm Center — Another day, another phishing campaign abusing google.com open redirects (May 2025)

• Sublime Security — Link: Google share.google URL shortener in google.<tld>/share.google path form and the attachment variant

• 9to5Google — Google app link shortener and the "Shorten links to web pages" setting (June 2025)

• Android Authority — That article you shared from Discover? It might be using a mysterious Google URL now (April 2025)

• Google Bug Hunters — Open redirectors

• Google — Safe Browsing site status and report a phishing page

• Netflix Help Center — Phishing and suspicious emails or texts

• PhishEye — The phishing page brand tools cannot find

• PhishEye — Behind the CAPTCHA: an S3-hosted Outlook credential phish

• PhishEye — Where Phishing Lives in 2026

• PhishEye — How to take down a phishing website in 6 steps

• PhishEye — How Fast Do Phishing Sites Come Down?

• PhishEye — Cloudflare Drop: instant hosting, phishing risk