Google App Password Phishing: Real Alert, Fake Threat

A phishing email landed in a PlayCISO inbox that Gmail authenticated as Google: DKIM and DMARC both passed. The sender, the signature, the branding and the "Check activity" button were all genuine. The only fake part was the text the attacker managed to place inside a real Google security alert, by typing it into the name of an app password. It plays on the fear that your account has already been compromised, and we expect a lot of people to fall for it.

Who this is for: anyone with a Gmail or Google Workspace account, and the security teams who train them.

Based on a message we received on 31 October 2026 and our reading of its headers. General facts about app passwords come from Google's help pages; facts about DKIM come from the DKIM standard (RFC 6376). PlayCISO is not affiliated with Google.

How the attack works

1. The trick: the lure goes into an app password's name

Google lets an account with 2-Step Verification create app passwords for older apps that cannot use modern sign-in, and you choose a name for each one. Google's security alert about a new app password repeats that name. The attacker uses the name field as a free-text box: the threat, a deadline, and a shortened URL. Google then builds its normal notification around that text and signs it.

2. The delivery: a real Google email, forwarded

The alert goes to the attacker's own account first, because it is the attacker's app password. They then forward it through another mailbox to the victim. Forwarding keeps the signed parts of the message intact, so when it arrives Gmail can still verify Google's DKIM signature, and DMARC passes because the From domain (google.com) matches the domain that signed it. In the message we received, Gmail recorded both as passing.

DKIM was never designed to stop this. It proves that a domain signed a particular message; it says nothing about who the message was meant for. The DKIM standard itself notes that a signed message can be replayed to other recipients. The technique is often called DKIM replay, and putting the lure in a name field that Google echoes back is what makes this version work.

3. Why it is convincing

• Everything you are trained to check is real: the Google sender, the signature, the logo, the layout and the "Check activity" button.
• The attacker's text sits inside that trusted template, so it reads as if Google wrote it.
• It starts from "you have already been compromised" and adds a 24-hour deadline. Panic makes people click before they think.
• The link the attacker wants you to use is separate from Google's own button: it is the shortened URL in the app password name.

4. The giveaways

• Wrong account. The alert, and the genuine "Check activity" button, refer to someone else's Google account, not yours. Check the account named in the body and the To line.
• A link inside the alert's wording. Google does not put shortened links in the name of an app password. Any URL in that part of the message came from whoever created the password.
• A false threat. "Permanent access after 24 hours" is not how app passwords work. You can revoke them at any time, and Google says they are revoked when you change your Google Account password.
• Odd forwarding traces. In "Show original", the message was delivered through a mailbox that is not Google's own, even though the signature is.

What to do if you get one

1. Do not click the shortened link, and do not use the "Check activity" button either: it opens someone else's account page.
2. Check your own account directly. Type myaccount.google.com into the browser and open Security. Look at Recent security activity, Your devices and App passwords. If there is nothing you do not recognise, you are fine.
3. Report it. In Gmail use the three-dot menu, then "Report phishing". At work, forward it to your security team the way they ask.
4. If you entered anything on the linked page, change your Google password from a page you opened yourself, remove unknown app passwords and devices, and tell your security team.

What security leaders should do this week

• Update awareness training: "it passed DKIM and DMARC" proves who signed an email, not that its content is honest. Show this example; it breaks the habit of trusting the sender line.
• Teach one habit above all others: never act on a security alert from a link inside it. Go to the account page directly.
• Add "whose account is this about?" to your phishing checklist. Replayed alerts are about someone else's account.
• Make reporting easy and make sure the security team triages "real-looking Google" reports, not just obvious fakes.
• Review app password use in Google Workspace. If no business process needs them, turn them off for your users; fewer people will then have a reason to trust an app password alert.
• Move privileged users to phishing-resistant MFA such as passkeys or security keys, so a stolen password or code is not enough.

Frequently asked questions

Can a phishing email really pass DKIM and DMARC for google.com?

Yes, if the email is a genuine Google message that has been re-sent. DKIM proves that the signing domain sent that exact content; it does not prove the message was meant for you. If the attacker gets Google to send a real notification that contains their text and forwards it without changing the signed parts, Gmail can still verify the Google signature, and DMARC passes because the From domain matches the signing domain.

How does the attacker get their text into a Google email?

In the message we received, the threatening text and a shortened URL sat where the app password's name normally appears. Google lets account owners name each app password, and its "new app password" alert repeats that name. The attacker set the name on their own account and forwarded the resulting alert.

How do I tell this phishing email apart from a real Google alert?

Check whose account the alert is about. A real alert names your own account; this one names a different address, and the genuine button points to that other account too. Then ignore any link in the alert's text and open myaccount.google.com yourself.

Does an app password give permanent access after 24 hours?

No. You can see and revoke app passwords at any time on the App passwords page of your Google Account, and Google says they are revoked when you change your Google Account password.

I clicked the link. What should I do?

Do not enter anything on the page. If you already typed a password or a code, change your Google password from a page you opened yourself, review Recent security activity and Your devices, remove app passwords you did not create, sign out unknown sessions, and tell your security team if it is a work account.

Why did the email filter not block it?

Filters lean heavily on sender authentication, and this message really was signed by Google. Report it with "Report phishing", and treat authentication results as proof of who signed a message, not proof that it is safe.

Practise spotting it

See how SPF, DKIM and DMARC decide what passes in the email authentication lab, test your eye in Pick the Phish, and if an account was touched, work through the identity compromise response checklist. For the longer-term fix, plan passkeys and security keys with the phishing-resistant MFA planner.

Sources

• The phishing message received by PlayCISO on 31 October 2026, including Gmail's authentication results (DKIM and DMARC pass for google.com).
• Google Account Help, "Sign in with app passwords": support.google.com/accounts/answer/185833 (managing and removing app passwords; it states: "To help protect your account, we revoke your app passwords when you change your Google Account password."). The custom app-password name and the alert that repeats it are as seen in the message we received.
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376.
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): rfc-editor.org/rfc/rfc7489.