Scam emails that really come from Google

Jameson Lopp, co-founder of the Bitcoin security company Casa, posted an “App password created” alert that was sent by Google’s own systems. The link in the message, he said, led to a phishing login page. The email was not spoofed. It was a genuine Google security notification carrying text that an attacker had placed in an app-password label.

The trick turns Google’s account-recovery plumbing into the envelope for the scam. The attacker creates a Google account, adds the target’s email address as its recovery address, and creates an app password whose name field contains a message: a case number, a phone number, or a link. Google then sends the target a real alert about that app password. The sender is Google, the template is Google’s, and the authentication checks pass. The dangerous part is the attacker-controlled text inside the message.

Switzerland’s National Cyber Security Centre described the pattern on September 22, 2026. The University of Michigan’s security team flagged an October 6 variant built around a fake $399 McAfee invoice and a support phone number. Lopp’s October 29 example used a Google shortlink in the alert. The details vary; the trust mechanism is the same.

The email is real; the message is not

The first thing to understand is that the message can be authentic in every technical sense. It is generated by Google, sent from a Google address, and signed by Google. It can pass SPF, DKIM, and DMARC because it really is a Google notification. Looking at the sender domain or the authentication results will not reveal the scam.

The victim receives it because their address is the recovery address on the attacker’s throwaway account. The account named in the alert is the attacker’s account, not the victim’s. That is why the message can say “your account” while showing an address the recipient does not recognize. The target does not need to own the Google account named in the alert, and the attacker does not need access to the target’s mailbox to trigger it.

In Lopp’s screenshot, the alert is titled “App password created to sign in to your account” and names a Gmail account. The body says that if the recipient did not generate the password, they have 24 hours to remove it by visiting a goo.gl link. The blue “Check activity” button and the myaccount.google.com/notifications link at the bottom are Google’s. The goo.gl link is the attacker’s text. Lopp said clicking it led to a phishing login page.

That distinction is the whole attack. The real Google links take the recipient to their own account, where nothing is wrong. The attacker’s link or phone number is the only path that leads to the scammer. The University of Michigan’s advisory describes the same dead end: “Clicking the legitimate Google account links lead to the recipient’s own clean dashboard, providing zero information or resolution.” The only actionable resolution left in the email is the attacker’s contact detail.

A real sender address is not a safety signal. A real security alert can be a real alert about the wrong account. The message is genuine; the request is not.

The attack chain

The Swiss advisory lays out the sequence in unusually clear terms.

1. Create a throwaway Google account. The attacker enters the victim’s email address as the account’s recovery address. Google uses that address for security notifications.
2. Enable two-step verification and create an app password. App passwords are available only on accounts with 2-Step Verification. The attacker sets one up on the throwaway account and puts the scam text in the app-password name field: a fake case handler, a case number, a phone number, or a URL.
3. Let Google send the alert. Google’s automated system sends the recovery address a genuine security warning. The attacker’s text is rendered into the message. In the Swiss case, the result looked like an urgent support case with a case handler and a case number.
4. Follow up by phone. Shortly after the email, the victim received a call from someone claiming to be Google support. The caller ID showed a Swiss number, but it was spoofed. The caller applied urgency and did not give up when the victim mentioned a hardware security key.
5. Send the victim to a fake login page. The caller redirected the victim to a page on sites.google.com. Google Sites is a legitimate service, so the domain looks trustworthy, but the page contained a malicious login form that sent the credentials to the attacker.
6. Create a backdoor. With access to the victim’s account, the attacker created an app password within minutes. The Swiss agency says this password allowed access without an additional two-factor prompt and continued to work after the victim changed the account password. In the reported case, emails and contacts kept syncing to a device abroad, unnoticed, for some time.

The Swiss advisory also documented an alert delivered by SMS that landed in the same message thread as earlier Google texts. The channel can vary. The common element is that Google’s own notification is used to establish credibility before the attacker asks for a click or a call.

The fake page is not hosted on accounts.google.com. The Swiss agency’s rule is exact: “Official Google login pages can only be found at ‘accounts.google.com’; they are never at ‘sites.google.com’.” Google Sites can host a page that looks like Google, but the login form on it is not Google’s.

A password manager may still offer to fill credentials on sites.google.com if the user has a legitimate Google Sites login saved. Autofill is not proof that the page is safe. The domain is real; the page is not Google’s account login.

The two app passwords

There are two different app passwords in this story, and conflating them makes the attack harder to understand.

The first password is not a compromise of the victim. It is a message-delivery mechanism. The second password is the compromise. That is why the initial alert can be real even when the victim’s account has not been touched yet.

Google’s documentation describes app passwords as 16-digit passcodes for less secure apps or devices. They are available only on accounts with 2-Step Verification, and Google says they are not recommended and unnecessary in most cases. They are bearer credentials: whoever has the password can use it, without a separate 2FA prompt. That is what makes the backdoor valuable.

Why it gets through

Most phishing advice assumes the attacker has to fake something. This attack does not. The sender is real, the template is real, and the message can carry valid Google signatures. There is no lookalike domain to spot in the From line and no obvious spelling error to catch.

The link can also look like Google. Lopp’s example used a goo.gl shortlink, a Google-owned domain. The Swiss and Michigan examples used a phone number; the MEGA analysis of an October 1 variant describes a link to sites.google.com. A trusted domain only says who hosts the page, not who wrote it. Google Sites and Google’s shortener are used by legitimate people and by attackers.

The University of Michigan case adds another layer. Its advisory says the alert was sent to the scammer’s recovery domain, routed through a compromised high school’s Microsoft 365 tenant, and auto-forwarded to U-M. Stacking valid Microsoft and Google DKIM/DMARC signatures helped the message pass all gateway checks. That is a supply-chain problem on top of a trust problem: the message was genuinely signed at each hop, but the content was still attacker-controlled.

The wording is also clean and urgent. The Google template supplies a 24-hour deadline. The attacker supplies a case number, a phone number, or a link. The result reads like an account emergency, not a grammar-laden phishing email. The real Google links showing a clean account can make the victim more confused, not less.

What Google says

Google’s guidance is unusually direct. The company says it will never call you about your account security. Its support page states: “Any unsolicited phone call, text, or email claiming to be from Google Security stating that your account has been compromised or hacked is always a scam.” It adds: “Google also never sends emails to verify callers. Any messages, even if sent from legitimate Google domains, that claim to validate a caller’s identity are fraudulent.”

That last sentence is the one to remember. A real Google domain does not make a message safe. If an email claims to be a security alert and asks you to call a number or click a link to validate a caller, the message is fraudulent even when Google generated it.

Google’s Gmail help page gives the safe verification path: if a security email looks fake, go directly to myaccount.google.com/notifications in a new tab. Do not use the link in the message. Google also says that if you are signed in, emails from Google will not ask you to enter the password for that account. If a page asks for it after a link click, close the page and navigate to Google yourself.

For app passwords, Google’s account help says they are not recommended and should be used only when an app or device cannot use “Sign in with Google.” It also says app passwords are 16-digit passcodes and require 2-Step Verification. The same page says: “To help protect your account, we revoke your app passwords when you change your Google Account password.”

The password-change caveat

That last Google statement conflicts with the Swiss agency’s observation. The NCSC says the app password the attackers created on the victim’s account continued to work after the victim changed the password. Google’s current documentation says app passwords are revoked when the account password changes.

The conflict is worth stating plainly rather than papering over it. The Swiss case may reflect a Workspace-specific path, a policy change since the incident, a timing detail, or a gap between documented and observed behavior. The public record does not resolve it. What is clear is that a password change alone is not a sufficient cleanup instruction after this kind of takeover. The Swiss agency’s advice is to go into the account’s security settings and delete every app password, without exception, then check recovery addresses and forwarding rules.

That advice is safe even if Google’s documented revocation works as described. Deleting the app passwords is explicit. Assuming they disappeared is not. The same logic applies to active sessions, connected devices, recovery addresses, and mail-forwarding rules: check them directly instead of trusting a single password change to undo an attacker’s access.

What is not established: the public record does not give the number of victims, establish that one group is behind every variant, or resolve whether Google has changed app-password revocation since the Swiss case. The technique is confirmed. The campaign’s size and attribution are not.

What to do

If you receive the email and have not clicked: do not use the link or call the number. Open myaccount.google.com/notifications in a new tab and check recent security activity. If you see an app password you did not create, remove it. If the alert names an account you do not recognize, that is a strong sign the message is about the attacker’s account, not yours.

If you clicked the link but did not enter anything: close the page, check your account activity, and report the message to Google. Do not reuse the link. If you downloaded a file, do not open it and scan the device.

If you entered your password or a code: change your Google password from myaccount.google.com, not from the email. Sign out active sessions, disconnect devices you do not recognize, delete all app passwords, and check recovery addresses and forwarding rules. If you reused the password elsewhere, change it there too. Turn on 2-Step Verification or a passkey if you have not already.

If you called the number: hang up. Do not share passwords, one-time codes, or approval prompts. If you installed remote-access software, disconnect the machine and clean it from a trusted device. If you gave payment information, contact your bank and the payment provider.

For organizations: mail filters are not enough, because the message is genuinely from Google and may carry valid signatures. Train users that a real Google notification can contain attacker text, and that the safe response is to open the account directly rather than use the email’s link or phone number. Review whether legacy app passwords are needed at all; Google itself says they are unnecessary in most cases. Prefer passkeys or security keys for account access, and keep recovery addresses and forwarding rules under review.

The uncomfortable lesson is that “it came from Google” is not the same as “Google wrote it.” The sender can be genuine, the signature can be valid, and the message can still be a scam. The only reliable check is to leave the message and open the account yourself.

Sources and references

• Swiss National Cyber Security Centre, Week 38: Genuine Google emails, fake support and a dangerous back door, September 22, 2026.
• University of Michigan Safe Computing, App password created to sign in to your account, October 6, 2026.
• Jameson Lopp, post on X, October 29, 2026.
• Google, Google Account Security Scam via Phone Call.
• Google, Avoid & report phishing emails.
• Google, Sign in with app passwords.
• MEGA, Fake Google security alert emails: when a real google.com link is still phishing, October 6, 2026.
• Foregenix, How Scammers Abuse Google’s Notification Emails to Phish Gmail Users, October 12, 2026.