How to Send DKIM-Signed, 100% Legit Phishing Emails — Straight from Google That Bypass Everything

Security researcher Nick Johnson (@nicksdjohnson) has revealed a highly sophisticated phishing attack that leverages two separate Google services — OAuth and Google Sites — to execute a multi-layered campaign capable of bypassing DKIM protections, abusing trusted infrastructure, and harvesting credentials, all while appearing completely legitimate to users and most email defenses.

This phishing method is particularly dangerous because it produces real, signed emails from no-reply@google.com, hosts phishing payloads on sites.google.com, and avoids the red flags typically used to warn users.

---

📬 Stage 1: Sending DKIM-Signed Phishing Emails via Google OAuth Abuse

🔧 How the Attack Works (Step-by-Step)

1. Set Up Malicious Infrastructure
   • Register a domain: attacker-cloud[.]com
   • Create a Google account: me@attacker-cloud.com
2. Create a Malicious Google OAuth App
   • In the OAuth consent screen, configure an app with:
     • App name: Entirely composed of a fake Google security alert, e.g.: csharpCopyEdit🚨 Google Security Alert 🚨 A new sign-in was detected from Chrome on Windows. Was this you? [Review Activity]
     • Add hundreds of spaces or line breaks, followed by: nginxCopyEditGoogle Legal Support Team
3. Authorize the App
   • When the attacker logs into this app, Google automatically sends a real security alert email to me@attacker-cloud.com, containing:
     • From: no-reply@google.com
     • Signed by google.com (DKIM: PASS)
     • Subject line and content fully customizable via the app name
4. Forward the Email to Victims
   • Because DKIM only signs headers and body, not the SMTP envelope, forwarding this email preserves the DKIM signature.
   • Gmail displays the forwarded message as:
     • Threaded with other security alerts
     • ✅ “No warnings”
     • ✅ “no-reply@google.com” with lock icon
     • ✅ “To: me” — a social engineering trick using the display name

---

🌐 Stage 2: Hosting Phishing Pages on Google Sites

• The email links (e.g., “Review Activity”) direct the user to: pgsqlCopyEdithttps://sites.google.com/view/google-security-center
• The attacker clones the Google login page using Google Sites and embeds:
  • A prompt to “Secure your account”
  • Fake login fields
• Once a user enters their credentials:
  • The information is sent to the attacker’s server
  • Optionally, the attacker collects session cookies, bypassing MFA

---

🧪 Why the Attack Is So Effective

Feature	Why It Works
DKIM Signed Email	Actually sent by Google, so it passes DKIM/DMARC/ARC checks
Google Branding	sites.google.com and no-reply@google.com lend total legitimacy
Gmail UI Behavior	Gmail shows the message as “To: me” with no banners
Visual Authenticity	The alert is threaded with real alerts, increasing trust
Link Destination	Domain is within google.com, bypassing both user suspicion and some URL filtering systems

---

🔐 Technical Flaws Exploited

1. OAuth App Name Injection

• Google allows OAuth apps to use long and misleading names.
• These names appear directly in the body of real security alerts.

2. Forwarding vs. DKIM Verification

• DKIM does not sign the SMTP envelope.
• When a signed message is forwarded, it remains valid — even if sent to a new victim.

3. Google Sites Trust Abuse

• sites.google.com allows attackers to host interactive HTML content.
• The use of a Google-owned domain tricks even savvy users.

---

🧠 Real-World Phishing Flow

textCopyEdit[1] Victim receives:
    📩 Email from no-reply@google.com
    📌 Subject: "Security Alert: A new app was granted access"

[2] Clicks “Review Activity”
    🔗 Link points to https://sites.google.com/view/fake-security-check

[3] Sees fake Google login page
    👤 Victim enters credentials

[4] Attacker collects:
    - Username + password
    - Session tokens (if possible)
    - MFA bypass or lateral access depending on scope

---

🧰 Defensive Recommendations

🔍 For Security Teams:

• ✅ Flag emails with OAuth app names embedded in alerts
• ✅ Monitor outbound access to sites.google.com/view/*
• ✅ Build detections for Gmail threads with forwarded Google security alerts
• ✅ Correlate logins preceded by link clicks to suspicious domains

📢 For User Awareness:

• 🚫 Never trust emails just because they pass DKIM or come from Google
• ✅ Confirm security alerts only by logging into https://myaccount.google.com
• ❌ Never enter credentials on sites.google.com — Google login only occurs at accounts.google.com

---

📣 Google’s Response

Initially, Google dismissed the issue as “working as intended” and not qualifying as a security vulnerability. However, after community backlash and growing visibility of the exploit, Google committed to addressing the OAuth abuse vector in a future update.

The Google Sites abuse issue, however, remains largely unresolved.