A phishing attack involving g.co, Google's URL shortener

Original Article ↗ Hacker News Discussion ↗

A sophisticated phishing campaign is exploiting what appears to be a Google Workspace bug that lets attackers register unverified `g.co` subdomains, add victims as users, and trigger real password-reset emails from `google.com` that pass SPF, DKIM, and DMARC. Combined with caller ID spoofing of a legitimate Google phone number and abuse of Google’s “tap to approve” 2FA flow, this makes the scam unusually convincing even to technically literate users. Commenters highlight the broader failure of phone-number trust, argue that no unsolicited call or security notification should be trusted, and recommend independently initiating contact via known-good channels instead of responding to inbound prompts.

Attack Mechanics and Google Workspace Bug

  • Many commenters focus on how a real-looking email from [email protected] passed SPF/DKIM/DMARC.
  • Consensus hypothesis: attackers created an unverified Google Workspace using a g.co subdomain (e.g., important.g.co), added the victim as a user or secondary email, then triggered a password reset.
  • This causes Google itself to send a genuine password-reset notification that references the fake g.co domain and passes all email-auth checks.
  • Several see this as a serious Workspace bug: allowing creation of Workspace tenants on g.co subdomains without domain verification and allowing some outbound emails from them.

2FA Prompt and Account Recovery

  • Clarification: the “code” the attackers knew was not a traditional 2FA code but the number shown during Google’s “tap a number on your device” prompt.
  • That number is displayed on the attacker’s screen during account recovery; the victim just has to tap the matching number on their phone.
  • This method is meant to prevent accidental approvals and credential-stuffing, not phishing; some argue a “type the 6-digit code” model would be safer, others note this is still MFA and requires both password and misclick.

Phone Calls, Caller ID Spoofing, and Verification

  • Strong consensus: no incoming call should be trusted, regardless of caller ID, accent, or claimed affiliation.
  • Recommended pattern: hang up, obtain a known-good number (card, prior bill, official site), and call back, ideally even from a different phone for high-value targets.
  • Several note telcos can technically detect spoofing (STIR/SHAKEN exists), but incentives and regulation are weak; some want strict blocking of spoofed IDs.

Critiques of “Best Practices” and User Blame

  • Multiple commenters argue the victim did not truly follow best practices: they verified a number on Google’s site but didn’t actually call it, and treated any valid Google-originating email as proof.
  • Others push back on blame, emphasizing this was far more sophisticated than common phishing and that even highly technical people get caught.

User Defenses and Tools

  • Suggested habits:
    • Treat all password-reset and fraud alerts as phishing unless you initiated them.
    • Never follow links or trust contact info in unsolicited messages; navigate manually.
    • Use password managers and rely on autofill domain checks; several say this has saved them from lookalike domains.
    • Use unique or aliased email addresses per service (catchalls, “Hide My Email”) to spot targeted phishing and data breaches.
  • Some advocate aggressive browser hardening (content blockers, per-site profiles), though others see this as too laborious for typical users.

Broader Concerns about Google and Abuse

  • Commenters note repeated abuse of various Google services (Workspace, AppSheet, Calendar, URL shortener) for phishing.
  • Some criticize Google’s slow or weak response to abuse and the difficulty of reaching real support, while others note that high-paying or enterprise customers do receive phone support.