A phishing attack slipped past even the most advanced email security systems — and it did so by exploiting a trusted feature used by major tech companies like Google. Hackers found a clever loophole in DKIM, a protocol designed to verify emails. Instead, they turned it into a tool to send fake, perfectly authenticated messages that looked exactly like official Google alerts, reaching inboxes without raising any red flag

The Setup:

🟢 STAGE 1: Initial Setup – Gaining a Legitimate DKIM-Signed Email

A threat actor begins by registering a new Google Account (e.g., me@maliciousdomain.com). They then create an OAuth application and cleverly name it with the entire phishing message content. Once the app is linked to their account, Google automatically sends a security notification to the attacker’s email, alerting about new access granted.

Google Account & OAuth App Creation

├── Attacker creates a Google account (e.g., me@maliciousdomain.com)

├── Attacker creates a custom OAuth app under this Google account

├── The app is named deceptively

e.g., “Google Security Alert | Review details https://sites.google.com/view/account-verify-center“,

         “Legal Notice – Google | https://sites.google.com/view/account-verify-center “

├── Attacker authorizes this app with their own Google account.

└── Google sends a real security alert email (e.g., “A new app has access to your account”) to the

          attacker’s Gmail account.

Here’s the trick: This notification comes from no-reply@google.com and is DKIM-signed with valid DKIM signature of google.com. It passes all the checks (SPF, DKIM, DMARC), because it truly was sent from Google infrastructure.

🟡 STAGE 2: Replay Setup via Outlook & Email Capture

Instead of crafting a new phishing email from scratch, the attacker cleverly reuses a legitimate, DKIM-signed security alert email sent by Google.

The attacker may use Outlook (or another mailbox) to store and extract the raw DKIM-signed message.

After receiving this email in their Outlook account (e.g., outlook-hack@outlook.com), the attacker extracts the entire raw message, including the headers and original DKIM signature, without making any modifications.

Capture DKIM-Signed Message

├── Attacker creates a free Outlook account (e.g., outlook-hack@outlook.com)

├── Auto-Forwards the Google alert to Outlook or receives it directly

└── Attacker opens the message in Outlook and copies the raw source (includes headers, DKIM-Signature, and full body)

✅ Note: Outlook is optional. The replay attack works as long as the attacker can get the raw DKIM-signed message and re-send it using a custom SMTP tool like Jellyfish.”

The Exploit:

🟠 STAGE 3: Replaying the DKIM-Signed Email via Jellyfish

The attacker leverages a custom SMTP tool like Jellyfish, which allows them to manually re-inject the raw email as-is. The forged email is then routed through an SMTP relay provided by Namecheap’s Private Email service—linked to a domain and mailbox under the attacker’s control (e.g., relay@evil-relay.com).

Replaying the Email via Jellyfish

├── Attacker uses Jellyfish SMTP or a custom SMTP script

├── Pastes the raw copied message into the tool

├── Preserves the original DKIM-Signature and content

└── Sets “From:” to no-reply@google.com

✅ What Jellyfish does:

•            Accepts full raw email input (headers + body)

•            Allows manually crafting headers, body, and DKIM signature

•            Manually injects the crafted message through any relay SMTP server (like Namecheap)”

🔴 STAGE 4: Sends the Forged Email via Namecheap’s SMTP Relay

SMTP Relay via Namecheap

├── Attacker registers a domain via Namecheap (e.g., evil-relay.com)

├── Purchases Namecheap Private Email plan

├── Creates a mailbox (e.g., relay@evil-relay.com)

├── Configures SMTP settings in Jellyfish:

• Host: mail.privateemail.com

• Port: 587 (STARTTLS)

• Auth: relay@evil-relay.com + password

├── Jellyfish uses these details to open a secure SMTP connection to Namecheap’s SMTP server.

└── Sends the forged Google security alert via Jellyfish → through Namecheap SMTP

✅ Result:

•            Email is sent from a non-Google server, but the DKIM signature is intact

•            Passes the email security checks like DKIM and DMARC

As mentioned above the security alert message includes an App name which has a link to a Google Sites page added by the attacker. This site mimics Google’s official support page but contains buttons that lead to a fake login page. Once the user enters their credentials, they are directly captured by the attacker.

🕸️ Stage 5: Victim Sees the Received Fake Email

├── Email message body contains links controlled by attacker

├── These links point to a Google Sites page designed to mimic:

• Google Support   • Google Legal Notice • Account Recovery

├── Page looks legitimate due to Google Sites domain

└── Fake page contains a “Sign in” button → redirects to a credential harvesting form

🔓 Step 5: Credential Harvesting

└── Victim enters login info on fake page → stolen by attacker

🔁 Step 6: Ongoing Abuse

├── Attackers can update phishing pages anytime

└── Hard to report abuse directly on Google Sites

Why it Worked:

✅ Genuine DKIM Signature:

The attacker used a real Google-generated email that was already DKIM-signed. Since DKIM checks the message content and headers—not the sending server—it still passed validation after being auto-forwarded without any change in the email body .

🌐 Trusted Google Infrastructure:

The phishing link was hosted on Google Sites, a legitimate platform. Most filters don’t flag Google domains, so the link looked safe and bypassed scrutiny.

🚫 No Domain Spoofing Involved:

The attacker didn’t forge headers or spoof domains. They replayed a real email, which meant traditional anti-spoofing tools like SPF, DKIM, and DMARC didn’t catch anything unusual.

💡 Legit-looking Content:

The message mimicked a standard Google security alert and even included familiar buttons like “View Case,” which built trust with the recipient.

📤 Forwarding, Not Sending:

The attacker forwarded the email using their own SMTP relay so while it came from elsewhere, the DKIM stayed intact—tricking security systems.

Lessons Learned:

Links, even under trusted domains, must be scrutinized.

What to Do:

Always hover over the link to see the full URL.

Look for strange subpages, extra words, or odd formats.

Don’t enter passwords or sensitive info unless you’re sure the page is real.

Platforms should consider abuse reporting mechanisms for legacy tools like Google Sites.

🔍 What is it?

Legacy tools like Google Sites are older but still-active platforms. They often lack built-in abuse reporting or modern security checks.

🚫 What can be prevented?

Phishing attacks hosted on trusted domains due to efficient abuse reporting.

Credential theft from fake Google login pages built on Google Sites.

Best Practices for Prevention:

1. Email Gateway Filtering: Deploy advanced email filters that scan for suspicious content, URLs, and attachments.

2. Multi-Factor Authentication (MFA): Require MFA for all critical systems to prevent unauthorized access—even if credentials are stolen.

3. Endpoint Protection: Use antivirus, anti-malware, and EDR tools on all devices.

4. Access Controls: Apply the principle of least privilege to minimize damage if an account is compromised.

5. Regular Patch Management: Keep all systems updated to close known vulnerabilities.

6. User Awareness Training: Educate employees to recognize phishing emails, fake domains, and social engineering tactics.