Verify it's you
Google blocked a suspicious sign-in attempt to your account.
To protect your account and files, confirm your identity. If this wasn't you, we'll pull your recent access logs so you can review and flag the activity.
Verifying your identity…
Google blocked a suspicious sign-in attempt to your account.
To protect your account and files, confirm your identity. If this wasn't you, we'll pull your recent access logs so you can review and flag the activity.
Review the events below. Select any activity you don't recognize, then click Report Selected Activity.
| Time | Device & Browser | Location | Sign-in Method | Status |
|---|
The data below was collected the instant your browser loaded this page — before any form interaction, before any button click. This is standard browser API exposure available to every website. A real attacker uses this data to pre-populate the "access logs" on page 2 with your actual browser and OS, making the familiar entries feel unmistakably like your account history.
Each stage of what you just experienced was engineered to exploit a specific, well-documented cognitive principle. These aren't tricks for the gullible — they are techniques that consistently work on security professionals, IT administrators, and executives. Understanding the mechanics is the only defense.
Urgency and fear suppress the prefrontal cortex's deliberate reasoning ("System 2") and activate the faster, pattern-matching amygdala response ("System 1"). The goal isn't to fool your logic — it's to prevent your logic from activating at all. "Someone in Nigeria is in your account right now" is designed to make you act before you think.
Google's own logo, loaded from Google's own CDN, on a URL that says google.com in the address bar, with a valid Google TLS certificate. Every visual and technical trust signal your brain uses to evaluate legitimacy was present. The page is hosted by Google. There was no lie to detect on those dimensions.
When you saw a table of access logs containing your real browser, your real operating system, and an approximate version of your location — you thought "they have my data." That belief established that this page has administrative access to your account. In reality, the "familiar" rows were fabricated from the browser fingerprint passively collected when you first loaded the page.
Checking boxes on the log table was a small, low-stakes action. But it was an action — a commitment. Cialdini's consistency principle predicts that once people make a small commitment, they're significantly more likely to make a larger, consistent one. You already participated in the security review. Now "confirm your recovery email" or "re-enter your password on the next step" feels like the natural completion of something you already started.
The log table showed mostly legitimate-looking entries, with only 2 pre-flagged suspicious ones. The ratio matters: a table of all-suspicious entries would look fabricated. The mix of familiar and suspicious anchors the viewer's belief that the system is real — because a fake system would just show the attack, not all the normal usage history around it.
By "giving you" your security logs and alerting you to the threat, the attacker created an implicit social contract: they did something for you, now you owe them cooperation. The ask to "confirm a few details" on the next step feels like a fair exchange for the protective service you just received. This is why the most sophisticated phishing doesn't just steal — it helps first.
The "familiar" rows in the access log table weren't pulled from a database. They were generated client-side using data your browser volunteered the moment the page loaded. Here's how the fabrication works.
The padlock was green. The domain read google.com. Zero browser warnings. Here's what was verified — and what wasn't.
/view/access-logs was unclaimed.
There is no vetting, no review, and no reservation process. Any anonymous person
can claim any available slug on sites.google.com/view/ for free, permanently,
using a throwaway Gmail account. The resulting URL passes every domain-reputation scanner
because the domain is genuinely google.com — hosted on Google's own CDN with Google's own TLS certificate.
4 minutes. $0. No identity verification. The /view/ prefix is exclusive to personal Gmail — not Workspace. Ironically it produces a URL that looks more like an internal Google property than the Workspace equivalent which embeds your org domain.
/view/access-logs, /view/security-alert, /view/account-recovery — first come, first served. Permanently. For free. The slug is the entire attack surface. Once claimed it cannot be removed without a Google manual intervention.
No-code WYSIWYG builder. Copies Google's fonts, colors, layout. Embeds Google's own logo assets loaded from gstatic.com — so resource requests in proxy logs look like Google talking to Google. Hosts a passive fingerprinting script to collect geo, browser, and device data on page load.
Urgent "Critical Security Alert" email — Google-branded, possibly sent via a Google product (Forms, Calendar invite, Docs share) for added legitimacy. The embedded link is a real google.com URL, so it passes SafeLinks, Proofpoint, and any URL scanner relying on domain reputation.
Using the passively collected browser fingerprint and geolocation data, the attacker generates a fake access log table populated with the victim's real browser, OS, and approximate city. The victim sees their own data reflected back and concludes the page has administrative access to their account. This is the moment trust transfers completely.
Selecting and submitting "unrecognized" log entries is a low-friction action, but it's a commitment. The victim has now actively participated in the security process. Cialdini's consistency principle means subsequent asks — confirm your password, enter your recovery phone, provide the 2FA code — feel like logical continuations of something already in progress.
Against SMS or TOTP-based 2FA, an Adversary-in-the-Middle proxy relays credentials to the real Google in real time, stealing the authenticated session cookie before 2FA can stop it. Against accounts with hardware keys (FIDO2/passkeys), this attack chain fails at this step — the key will not authenticate to a non-canonical origin.
With a valid session cookie, the attacker has full account access. The victim is silently redirected to the real myaccount.google.com — which looks like "the verification worked." From here: email exfiltration, OAuth app persistence for long-term access, lateral movement to any SSO-connected application, or credential resale.
Hardware keys (YubiKey, Google Titan) and device passkeys cryptographically bind authentication to the exact origin. They will not authenticate a session on sites.google.com for credentials stored for accounts.google.com. SMS OTPs and TOTP codes do not have this property — they are relayed by an AiTM proxy in real time.
Requires two hardware keys. Enforces stricter OAuth app restrictions and account recovery controls. For high-value targets — executives, security professionals, journalists — this is non-negotiable. Enrollment at landing.google.com/advancedprotection.
Password managers bind credential autofill to the exact origin. They will not autofill sites.google.com with credentials saved for accounts.google.com. If your password manager hesitates, your brain should stop completely.
Google's authentication lives at accounts.google.com. If you're asked to log in under any other google.com path, treat it as compromised until proven otherwise. The padlock certifies the domain. It says nothing about who controls the page.
The engineering of fear and time pressure is deliberate. Google's genuine security alerts direct you to myaccount.google.com/security directly — they do not embed login forms or access logs in linked pages. Navigate there manually. Never via a link in an alert.
If you've already taken a small action on a page (checked boxes, confirmed an email, answered a question), notice that you've been primed. The natural instinct is to continue — because stopping feels inconsistent with what you just did. Stop anyway. Consistency is a feature of trustworthy behavior, not a reason to ignore warning signs.