Caught Live: The Google Calendar Invite Built to Steal a Password

Threat vector

Google Calendar invite → multi-hop redirect → credential-harvesting page

Delivery lure

A “Listen to Recording” prompt inside the invite

Final destination

A page built to mimic Google’s own account sign-in flow

Determination

Suspicious: verify before acting (credential-harvesting phishing)

Confidence

High · 90%

Published

September 15, 2026

Prepared by

Backgrounder

Status

Public brief, Fraud Watch series

Caught Live, Not Reconstructed After the Fact

Most of what follows in this brief is reconstructed after the fact: domain records, hosting history, a redirect chain traced hop by hop. Carmen Monitor, the Backgrounder browser extension, flagged the destination page in real time, before the person on the other end of it ever typed a password into it.

The rest of this brief works backward from that moment: how the invite reached a calendar in the first place, what the redirect chain was built to do, what the destination page actually was, and what a security team would want handed to them if this showed up in their own environment.

How the Attack Unfolded

Laid out in order, the chain runs six hops from an ordinary-looking calendar notification to a page built to steal a Google password. Each one only makes sense in light of the one before it.

Step 1 · The Lure — An invite, not an email

An invite appears directly on the calendar, carrying a single prompt: “Listen to Recording.” Calendar invites travel through infrastructure that many spam filters treat as trusted, and they can land on a calendar without ever passing through an inbox the way a normal email would.

Step 2 · The First Hop — Google's own link redirector

Clicking the prompt first passes through Google's own outbound redirector, google.com/url, carrying a source=calendar parameter that confirms where the click originated, alongside a second timestamp parameter (ust=) tied to the same calendar delivery mechanism. For a moment, a genuine google.com address sits in the browser bar, a detail a hurried reader is likely to read as reassurance before the handoff continues.

Step 3 · The Obfuscation Layer — The same tracking domain, nested four times

From there the link is wrapped inside Postmark's transactional email click-tracking domain, track.pstmrk.it, four times in a row, each layer URL-encoded inside the one before it and each carrying its own distinct tracking identifier, consistent with per-recipient tracking rather than one reused link. A single tracking wrapper is routine. Four nested layers of the same domain is not, and is consistent with an attempt to outlast automated link scanners that unwrap a redirect once or twice and then stop. Postmark itself checks out as legitimate infrastructure, with an extensive footprint across dozens of unrelated, legitimate domains, confirming this is real transactional email infrastructure being abused rather than a lookalike.

Step 4 · The Relay — A waypoint with no content of its own

The chain surfaces at hradypredeti.sk, a Slovak domain roughly three and a half years old, hosted in Frankfurt on ordinary cPanel and LiteSpeed infrastructure. The domain shows nothing; it simply forwards the click again, through a specific path inside what looks like a compromised WordPress install rather than a purpose-built redirect script. Other subdomains on the same hosting account resolve to the same IP address, consistent with a single compromised account rather than dedicated attacker infrastructure. That age, hosting profile, and path all fit a legitimate small-business site that has been compromised or rented, not infrastructure purpose-built for this chain.

Step 5 · The Destination — A page built to mimic Google, not to be Google

The final hop lands on 7e5412.nunline-enterprisebusinevervicounation.org, registered only 14 days before this chain was observed, through the registrar Spaceship, Inc., and hosted behind Cloudflare. It has no footprint at all in the Wayback Machine or CommonCrawl, the mark of a domain stood up fresh rather than one with any history. Its own URL carries Google's exact sign-in parameters, including flowName=GlifWebSignIn, service=mail, and continue=mail.google.com, on a domain with no connection to Google. Zero of seven standard security headers are present. Two additional ports, 8080 and 8443, are open beyond what a static phishing page needs.

Step 6 · The Catch — Flagged before a password was typed

Before any credentials could be entered, Carmen Monitor flagged the page as high priority. The chain above shows what the page was built to survive.

Technical Analysis

Two things make this chain worth a closer look rather than a one-line “don't click it”: it was built to survive automated scanning, not just to fool a person in a hurry, and its destination was built to mimic a specific, real authentication flow rather than a generic login box.

A chain built to survive scanning, not just to fool a person

A single link-tracking wrapper is routine. Marketing platforms and transactional email services use them constantly, and most automated URL scanners know how to follow one hop through a known tracking domain. Nesting the same tracking domain inside itself four times, as this chain does with track.pstmrk.it, is different: it is consistent with an attempt to exhaust scanners that give up after one or two hops, while a human clicking through never notices the difference. Each of the four nested layers carries its own distinct tracking identifier, consistent with per-recipient tracking rather than one reused link. Layering a second, unrelated relay domain, hradypredeti.sk, on top of that is consistent with a two-tier infrastructure pattern: one piece absorbs the scanning and reputation risk, the other holds the actual page. Postmark itself checks out as legitimate infrastructure, with an extensive footprint across dozens of unrelated, legitimate domains, confirming this is real transactional email infrastructure being abused rather than a lookalike.

The relay site behind the redirect

The relay hop at hradypredeti.sk forwards through a specific path inside what looks like a compromised WordPress install, rather than a purpose-built redirect script. Other subdomains on the same hosting account resolve to the same IP address, consistent with a single compromised or rented hosting account rather than dedicated attacker infrastructure. Nothing in this brief identifies the account holder, since the available evidence points to compromise of an existing legitimate site rather than complicity in the campaign.

A landing page built to mimic Google, not to be Google

The destination domain is 14 days old, which by itself is a weak signal. Plenty of legitimate sites are new. What strengthens it here is the combination: a domain with no brand relationship to Google, carrying Google's own OAuth sign-in parameter names in its URL, hosted behind Cloudflare with none of the seven standard security headers a real authentication endpoint would carry, and with two extra ports open that a static credential-capture page has no ordinary reason to need. Individually, several of these are common on small, hastily built sites. Together, and pointed at Google's sign-in flow specifically, they indicate infrastructure built for one purpose.

That same contrast shows up in the historical record. The tracking domain abused earlier in the chain has hundreds of snapshots in the Wayback Machine and a presence in CommonCrawl, the ordinary footprint of infrastructure that has been running for years. The destination domain has none, in either archive. A domain with zero history anywhere on the public web, built specifically to carry Google's own sign-in parameters, is a stronger signal together than either fact is alone.

What Carmen's own investigation found

Asked directly about the two domains in this chain, Carmen's automated analysis returned a 90% confidence “Suspicious: verify before acting” determination, citing the fresh registration, the Google login-flow redirect pattern, and the absence of email authentication on the domains involved. The full, unedited analysis, including the OSINT enrichment Carmen drew on for hosting, registration, and infrastructure detail, is reproduced in Appendix A.

A Related but Separate Finding

While this case was being researched, a separately reported phishing email was also submitted to Ask Carmen: a message using the address tom.komuro@svinnovations.com, reported by a different submitter as having been used against a different target. It is not established that this is the same operator or the same campaign as the calendar-invite chain above. The submission included no original message to analyze, only the address itself and a description, which is why Carmen's initial read came back inconclusive before a deterministic risk signal promoted it to a scam determination at 77% confidence. It is included here, in Appendix B, because it surfaced in the same investigation window and shows a related pattern worth knowing about: a freshly stood-up payment subdomain riding on an old, otherwise ordinary-looking parent domain.

What We'd Send a Security Team

The rest of this brief is written for a general reader. This section is the condensed package Backgrounder would hand to an IT or security team investigating this specific chain: indicators, detection ideas, and the response steps if someone in the organization clicked through.

Indicators observed

Detection ideas

• •Flag calendar invites whose links route through Google's own google.com/url redirector into a chain of link-tracking domains, particularly where the same tracking domain appears nested more than once.
• •Alert on outbound URLs carrying Google OAuth parameter names (flowName=GlifWebSignIn and similar) on any domain outside Google's own infrastructure.
• •Treat “Listen to Recording,” “Voicemail attached,” and similar audio-message prompts inside calendar invites as a known lure pattern worth a standing detection rule, not a one-off.

If someone in your organization clicked through

• 1.Treat the account as potentially compromised. If credentials were entered on the fake page, change the password immediately and revoke active sessions.
• 2.Review OAuth app grants and mail-forwarding rules on the affected account. Both are common ways an attacker keeps access after a password change.
• 3.Enable or verify a hardware security key on the account rather than relying on SMS or app-based two-factor alone.
• 4.Check recent sign-in activity at myaccount.google.com/security for any unfamiliar location or device.
• 5.Preserve the original calendar invite rather than only a forwarded copy or screenshot. The invite itself carries sender and routing metadata a screenshot won't.

Reporting

• •Report the phishing domain to Google via safebrowsing.google.com/safebrowsing/report_phish, since it specifically impersonates Google's own sign-in flow.
• •Report the relay domain to its host for abuse review, and the phishing domain's hosting provider separately. Both can act faster than a registrar in many cases.
• •If the calendar invite can be traced to a specific sending account, consider notifying Postmark's abuse team, since its tracking infrastructure was used as an obfuscation layer in this chain.

This section names infrastructure observed in one incident, current as of this brief's publication date. It is not a claim that any of these domains, hosts, or services are complicit. A relay domain in a chain like this is very often itself a victim of compromise.

If You Get an Invite Like This

• 1.Don't click audio-message prompts in calendar invites you weren't expecting. “Listen to Recording,” “Voicemail attached,” and similar prompts are a known lure. A calendar invite is not how anyone legitimately delivers a voicemail.
• 2.Verify through a separate channel if the invite claims to come from someone you know. A text or a call costs a minute; a stolen Google account costs much more.
• 3.If you already clicked and entered a password, change it immediately, enable a hardware security key or strong two-factor authentication, and review your account's recent sign-in activity and any mail-forwarding rules at myaccount.google.com/security.
• 4.Report the invite to Google. Open it, use the three-dot menu, and select “Report as spam.” This helps Google block the sender and protect others who may have received the same invite.
• 5.Tell your IT or security team if this arrived at a work address. Calendar-based phishing campaigns often target several people at the same organization at once.

About This Brief

Backgrounder is a company that uses AI to detect scams. This brief is part of an ongoing Fraud Watch series examining live threats and the techniques used to evaluate them, published for general awareness. It reflects a chain observed and analyzed through September 15, 2026, and, like any brief tied to a single point in time, may not reflect infrastructure changes after that date. Domains, hosting, and DNS records can and do move.

Sources

The redirect chain and destination page were observed directly and flagged in real time by Carmen Monitor, the Backgrounder browser extension. Domain registration, hosting, and infrastructure detail for hradypredeti.sk and 7e5412.nunline-enterprisebusinevervicounation.org come from Ask Carmen's OSINT enrichment, reproduced in full in Appendix A. The related finding on tom.komuro@svinnovations.com comes from a separate Ask Carmen submission from the same investigation window, reproduced in full in Appendix B.

Appendix A: Ask Carmen's Full Analysis of the Phishing Links

The full, unedited Ask Carmen analysis of the two domains in the redirect chain, reproduced in full for anyone who wants the underlying detail rather than the summary above.

Suspicious profile: fresh domain (14 days) with Google login-flow redirect pattern and no email authentication.

What I Found

• •Domain registered only 14 days ago; no Wayback or certificate history. A fresh artifact appearing in a transactional context (an OAuth redirect) is a stronger signal than a fresh domain alone.
• •The URL contains GlifWebSignIn flow parameters and a continue= redirect to Google Mail. The obfuscated subdomain (7e5412) combined with a nonsensical domain name (nunline-enterprisebusinevervicounation) is a classic phishing pattern.
• •An incoherent domain name with no legitimate business identity, registered via a budget registrar. No supporting technologies, no email authentication posture.
• •An authoritative reputation feed returned clean; however, fresh artifacts often evade detection for hours to days after registration.
• •No SPF, DKIM, or DMARC configured on a domain claiming to handle authentication flows.
• •No reputation corpus has indexed the domain, consistent with brand-new phishing infrastructure.
• •Zero presence for the phishing domain in the Wayback Machine or CommonCrawl, versus hundreds of archived snapshots for the abused Postmark tracking domain. A domain with no history anywhere on the public web is a stronger signal alongside the 14-day registration than the registration date alone.
• •The relay forward at hradypredeti.sk resolves through a specific path consistent with a compromised WordPress install rather than a purpose-built redirect script. Other subdomains on the same hosting account share a single IP address, consistent with one compromised account rather than dedicated attacker infrastructure.
• •Each of the four nested Postmark tracking layers carries its own distinct tracking identifier, consistent with per-recipient tracking rather than a single reused link.

What You Should Do Next

• •Do not click or interact with this link. Do not enter credentials. Verify any authentication request directly with Google or your email provider through official channels (phone, official website). Report the URL to Google Safe Browsing and your email provider's abuse team immediately.
• •Do not click either link. If you have already clicked nunline-enterprisebusinevervicounation.org and entered any credentials, change your Google account password immediately and review your account's recent activity at myaccount.google.com/security.
• •If you entered credentials on the fake page, enable two-factor authentication on your Google account right now and check for any unauthorized sign-ins or forwarding rules added to your Gmail.
• •Report the malicious calendar invite directly to Google: open the invite, click the three-dot menu, and select “Report as spam.” This helps Google block the sender and protect others.
• •Preserve evidence before deleting: screenshot the calendar invite showing the sender's address and the links, and note the full URL of the phishing link. This is useful if you report to your IT team or file with the Anti-Phishing Working Group at reportphishing.apwg.org.
• •If this arrived at a work email address, notify your IT or security team immediately. Google Calendar phishing campaigns often target multiple people at the same organization simultaneously.
• •Report the Cloudflare-hosted phishing domain (7e5412.nunline-enterprisebusinevervicounation.org) to Cloudflare abuse immediately. They can null-route it within hours.
• •Report to Google's phishing team via safebrowsing.google.com/safebrowsing/report_phish so Chrome and Gmail can block it.
• •Investigate hradypredeti.sk as a potentially compromised hosting account and notify its registrar (UBOM-0334) and host (WHG/A2 Hosting).
• •If any credentials were entered, treat the Google account as fully compromised: revoke all sessions, rotate the password, and enable a hardware security key immediately.

Analysis

This is a Google credential phishing attack delivered via a Google Calendar invite. The primary phishing link at nunline-enterprisebusinevervicounation.org is designed to mimic Google's OAuth sign-in flow by using Google's exact authentication parameters in the URL, while the actual page is hosted on a nonsense domain with no connection to Google. The attacker's goal is to capture the victim's Google account username and password. A second domain, hradypredeti.sk, appears in the same attack and likely serves as a redirect intermediary. The use of Google Calendar as the delivery vehicle is a deliberate evasion technique.

OSINT Intelligence: The new OSINT confirms the phishing domain is live and active: 14 days old, resolving to Cloudflare, SSL provisioned, zero security headers, with extra ports open suggesting tooling beyond a simple phishing page. It also carries no footprint in the Wayback Machine or CommonCrawl, the mark of a domain stood up fresh for this campaign rather than one with any history. The hradypredeti.sk cluster resolves consistently to a Frankfurt host running cPanel/LiteSpeed, forwarding through a path consistent with a compromised WordPress install, with other subdomains on the same account sharing one IP address, strongly indicating a single compromised legitimate hosting account used as a redirect tier. Nothing in the enrichment data exculpates any element of this attack. Confidence moves from 0.92 to 0.97.

Things to Watch For

• •The link at nunline-enterprisebusinevervicounation.org uses Google's exact OAuth sign-in parameters (flowName=GlifWebSignIn, service=mail, continue=mail.google.com) on a domain that has no connection to Google. This is the phishing mechanism itself.
• •nunline-enterprisebusinevervicounation.org is a high-entropy, algorithmically structured nonsense domain, characteristic of throwaway phishing infrastructure.
• •Delivery via Google Calendar invite is a known evasion technique: attackers use it because Calendar notifications appear to come from Google and bypass many email security filters.
• •A second suspicious domain, hradypredeti.sk, appears in the same attack, suggesting a redirect chain or multi-stage infrastructure.
• •The goal of this attack is Google account credential theft. If clicked and credentials are entered, the attacker gains full access to the victim's Gmail, Google Drive, and any linked services.
• •The phishing domain was registered just 14 days ago via Spaceship, Inc. and is actively resolving to Cloudflare IPs, confirming live, operational infrastructure rather than a dead or speculative threat.
• •Zero of 7 security headers are present on the phishing URL, consistent with a hastily deployed credential-harvesting page rather than any legitimate service.
• •The hradypredeti.sk ecosystem (registered ~3.5 years ago, hosted on A2/WHG in Frankfurt, running LiteSpeed with cPanel subdomains) appears to be a compromised or rented legitimate hosting account used as a redirect or payload stage: a classic two-tier phishing infrastructure pattern. The forward runs through a specific WordPress path rather than a purpose-built script, and other subdomains on the same account share one IP address, both consistent with a single compromised account rather than dedicated attacker infrastructure.
• •Open ports 8080 and 8443 on the phishing host suggest additional attack tooling or C2 channels beyond the primary phishing page.
• •The phishing domain has zero presence in the Wayback Machine or CommonCrawl, in contrast to the abused Postmark tracking domain, which has hundreds of archived snapshots and a long, ordinary history. That contrast reinforces the 14-day registration date as a signal of purpose-built infrastructure.
• •A 2fmail.google.com domain that does not resolve is likely a decoy or obfuscation element inserted to confuse automated scanners into associating the attack with legitimate Google infrastructure.

Appendix B: A Related Ask Carmen Submission

This is a separate submission from the same investigation window, concerning a different reported phishing email and a different target. It is reproduced here for completeness, per the same “detailed analysis belongs in an appendix” approach as Appendix A. This is not because a direct link to the calendar-invite chain above has been established. Read it as a related pattern, not a confirmed continuation of the same case.

How to Protect Yourself

• •Share the actual phishing email. Forward it as an attachment, not inline, so the full headers are preserved. That's what will let us determine whether tom.komuro@svinnovations.com was the real sender or was spoofed by someone else.
• •Contact svinnovations.com directly through their official website (not any contact info in the suspicious email) to report that their domain or an employee account may have been used in a phishing attempt. If the account was compromised, they need to know.
• •If the targeted person clicked any links or entered any credentials in response to the phishing email, they should change their passwords immediately and enable two-factor authentication on any affected accounts.
• •Preserve all evidence. Save the original phishing email, any screenshots, and note the date and time it was received. This will be important if you need to report to law enforcement or the relevant platform.
• •Do not interact with any links pointing to pay.svinnovations.com. The payment subdomain on AWS with minimal security headers is the highest-risk element here.
• •Verify the legitimacy of svinnovations.com through independent channels (company registry, LinkedIn, direct phone) before treating any communication from this domain as authentic.
• •If you received a payment request, confirm it through a separately sourced contact number, not one provided in the suspicious email.

Analysis

The submitter is asking about the email address tom.komuro@svinnovations.com, which they report was used in a phishing attempt on another person. No actual phishing message was provided. Only the email address and a brief description were given. Without the original message, headers, authentication, content, and links could not be analyzed. The entity risk score is low (15/100) and no historical database matches exist for this selector. The address follows a standard corporate email pattern. The verdict is inconclusive: the submitter's report is a real signal, but there is insufficient independent evidence to confirm or deny that this address was involved in phishing.

OSINT Intelligence: The new OSINT substantially shifts this assessment. The parent domain svinnovations.com is genuinely old (13+ years, GoDaddy/Google infrastructure), but the pay.svinnovations.com subdomain, the likely phishing vector, sits on fresh AWS infrastructure with almost no security hardening and zero web history, a classic pattern for a legitimate-looking domain being abused for a payment scam. Combined with no email authentication (DKIM/DMARC absent), spoofing or subdomain hijacking is plausible and the risk is real.

Automated override: the automated analysis above concluded no determination; this case is recorded as scam. Reason: a decisive deterministic signal fired (critical=0, high=4) at a risk score of 0.77, at or above the 0.25 promotion bar.

Things to Watch For

• •The submitter reports this email address was used in a phishing attempt. This is the primary signal and warrants investigation.
• •No actual phishing message was provided, so the nature and authenticity of the attempt cannot be independently verified.
• •It is unknown whether the address was the true sender or was spoofed. Without original headers, the real origin is unconfirmed.
• •The svinnovations.com domain is 13+ years old and registered via GoDaddy with Google-hosted DNS/MX, consistent with a real business. But the pay.svinnovations.com subdomain resolves to AWS EC2 instances with only 1 of 7 security headers and no Wayback history, a pattern common in hastily stood up payment pages.
• •RDAP returns “not registered” for all three svinnovations.com variants despite DNS resolving. This contradiction suggests a data inconsistency or unusual registration state that warrants scrutiny.
• •No DKIM selectors and no DMARC policy on the sending domain means anyone could spoof tom.komuro@svinnovations.com without authentication failures.
• •The email address has zero reverse-WHOIS domain associations, suggesting the persona has no administrative footprint despite the domain's age.
• •A decisive risk pattern was detected, promoting this case from no-determination on a high-confidence deterministic signal that converged with the overall risk score.