You receive an email from PayPal. It looks perfect — logo, formatting, footer, the works. But something feels slightly off. The question is: do you know where to look?

In this article, we walk through a realistic phishing email from start to finish, analyzing each layer with Security Decoder — our free browser-based analyzer. No installs, no data sent anywhere, all logic runs locally in your browser.

TL;DR

  • Phishing emails contain multiple layers of deception — headers, URLs, payloads, and obfuscated scripts
  • Email headers (SPF/DKIM/DMARC) are the first thing to check — they reveal whether the email actually came from who it claims
  • Phishing URLs use homoglyphs and open redirects to bypass visual inspection
  • Attackers embed JWT tokens and Base64-encoded JavaScript to hide malicious payloads
  • You can analyze all of these in seconds with Security Decoder — no tools to install

Table of Contents

The Email We're Analyzing

The scenario is one of the most common attack patterns in 2026: a fake PayPal security alert. Here’s a simplified version of what the raw email looks like behind the scenes:

Received: from mail.paypa1.com (45.33.32.156) by mx.victim.com
From: "PayPal Security" <security@paypa1.com>
Reply-To: noreply@paypa1-secure.support
Subject: ⚠️ Urgent: Suspicious login detected — verify your account


Dear valued customer,


We detected a suspicious sign-in to your account from Russia (Moscow).
If this wasn't you, please verify your account immediately:


https://paypa1.com/secure/verify?token=eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
  .eyJ1c2VyIjoiam9obi5kb2VAZXhhbXBsZS5jb20iLCJyb2xlIjoic3VwZXJ1c2VyIiwiZXhwIjoxNzQwMDAwMDAwfQ.
&redirect=http%3A%2F%2Fevil.example.com%2Fsteal
&js=ZXZhbChhdG9iKCdZV3hsY25Rb1pHOWpkVzFsYm5RdVkyOXZhMnNvS1En
  KSk7YWxlcnQoZG9jdW1lbnQuY29va2llKQ==


PayPal, Inc.
2211 North First Street, San Jose, CA 95131

This is engineered to look legitimate. Let’s pull it apart layer by layer.

Step 1: Email Headers — SPF, DKIM, DMARC

The first thing an analyst does with a suspicious email is look at the raw headers — the metadata that travels with every email and tells the story of where it actually came from.

Most email clients hide these by default. In Gmail: three dots → Show original. In Outlook: File → Properties. Copy the entire header block.

Paste it into Security Decoder. The tool automatically detects email header format and breaks it down:

What Security Decoder finds:

CheckResultWhat it means
SPF❌ FAILThe sending server 45.33.32.156 is not authorized to send email for paypa1.com
DKIM❌ No signatureThe email was not cryptographically signed by PayPal
DMARC❌ FAILNeither SPF nor DKIM passed — the domain policy would flag this as fraudulent
Originating IP45.33.32.156A Linode VPS — geolocates to the US but flagged on AbuseIPDB

What these mean in plain English:

  • SPF (Sender Policy Framework) is a list that says “these are the servers allowed to send email from our domain.” The phishing server isn’t on PayPal’s list — it’s a rented VPS.
  • DKIM (DomainKeys Identified Mail) is a cryptographic signature that proves the email wasn’t tampered with and really came from the domain. There’s no signature here at all.
  • DMARC is the policy that ties SPF and DKIM together and tells receiving servers what to do when they fail. A legitimate PayPal email would pass both.

The Reply-To header is also a giveaway: paypa1-secure.support — a lookalike domain registered specifically for this campaign. Any reply you send goes to the attacker, not PayPal.

Step 2: The Phishing URL

The link in the email looks plausible at a glance: paypa1.com. But paste it into Security Decoder:

https://paypa1.com/secure/verify?token=...&redirect=http%3A%2F%2Fevil.example.com%2Fsteal

What Security Decoder finds:

  • Homoglyph substitution: paypa1.com uses the digit 1 instead of the letter l. The human eye reads it as “paypal” — the brain autocorrects. Security Decoder flags this explicitly.
  • Brand impersonation keyword: The domain contains “paypa” — a known brand keyword pattern used in typosquatting campaigns.
  • Open redirect: The redirect= parameter contains a URL-encoded value (http://evil.example.com/steal). After “verifying” your account, you’d be silently forwarded there. Open redirects are often used to bypass email filters that check the destination URL — the filter sees paypa1.com and passes it.
  • Suspicious query parameters: Multiple encoded values in the URL string — token, redirect, and js — all packed together. The js= parameter is especially unusual for a login link.

The URL-encoded redirect decodes to: http://evil.example.com/steal — the actual credential harvesting endpoint.

Step 3: JWT Token in the Link

The token= parameter in the URL is a JWT (JSON Web Token) — a common format for passing authentication data. Legitimate services use JWTs. So do attackers, to pre-fill victim data and track clicks.

Take the token value and paste it into Security Decoder:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
.eyJ1c2VyIjoiam9obi5kb2VAZXhhbXBsZS5jb20iLCJyb2xlIjoic3VwZXJ1c2VyIiwiZXhwIjoxNzQwMDAwMDAwfQ.

What Security Decoder finds:

// Header (decoded)
{
  "alg": "none",
  "typ": "JWT"
}


// Payload (decoded)
{
  "user": "john.doe@example.com",
  "role": "superuser",
  "exp": 1740000000
}

Two critical findings:

  1. alg: none — This is a well-known JWT vulnerability. A token with algorithm “none” has no cryptographic signature — any server naively accepting it would trust the claims inside without verification. The attacker is testing whether the target site accepts unsigned tokens.

  2. role: superuser — The attacker has pre-set the victim’s role to superuser in the token payload. If the receiving server trusts this token blindly, it would grant admin-level access.

  3. Expiry check: The exp timestamp (1740000000) converts to February 2025 — this token is already expired. A red flag that this is a template reused across campaigns, not a fresh token.

This tells us two things: the attacker is attempting JWT exploitation on the target application, and the victim’s email address was already known before the email was sent — this is a targeted attack, not a random spray campaign.

Step 4: Obfuscated JavaScript Payload

The js= URL parameter is the most dangerous part. It’s Base64-encoded. Paste the value into Security Decoder:

ZXZhbChhdG9iKCdZV3hsY25Rb1pHOWpkVzFsYm5RdVkyOXZhMnNvS1EnKSk7YWxlcnQoZG9jdW1lbnQuY29va2llKQ==

What Security Decoder finds:

// Decoded output:
eval(atob('YWxlcnQoZG9jdW1lbnQuY29va2llKSk='));alert(document.cookie)

Then decoding the inner Base64 layer:

alert(document.cookie)

This is a double-encoded XSS payload — a JavaScript cookie stealer wrapped in two layers of Base64 encoding, designed to bypass filters that scan for the word “cookie” or “document” in URLs.

The eval(atob(...)) pattern is a classic obfuscation technique:

  • atob() decodes Base64 — a built-in browser function that can’t be blocked without breaking legitimate sites
  • eval() executes whatever string it receives as JavaScript code
  • Layering them with double encoding means a simple regex filter won’t catch it

Security Decoder flags this as: JavaScript obfuscation detected — eval/atob pattern, possible XSS, cookie exfiltration.

If the target application reflects this URL parameter into an HTML page without sanitization, this payload executes and the victim’s session cookies are sent to the attacker.

Putting It All Together

What started as a “suspicious login alert” from PayPal is actually a multi-stage attack:

  1. Delivery: Email spoofed with a homoglyph domain, SPF/DKIM/DMARC all failing — but many mail servers still deliver it
  2. Lure: Urgency (“suspicious login from Russia”) triggers an emotional response that bypasses rational evaluation
  3. Redirection: An open redirect hides the real destination; the victim sees a familiar domain name in the link
  4. Session takeover: A JWT with alg:none attempts to hijack the session if the server is vulnerable
  5. Cookie theft: A double-encoded XSS payload steals session cookies if the application reflects URL parameters
  6. Exfiltration: The redirect= parameter sends the victim — and their credentials — to the attacker’s server

This is not a simple “click here to get hacked” email. It’s a layered attack targeting both the user and the application simultaneously. Even if the user is careful, a vulnerable application could be exploited directly.

What You Can Do Today

If you receive a suspicious email:

  1. Don’t click any links — copy the raw URL instead
  2. Check email headers for SPF/DKIM/DMARC failures
  3. Paste any URLs, tokens, or encoded strings into Security Decoder
  4. Report the email to your IT/security team with the full raw headers attached

If you run a web application:

  • Enforce DMARC with p=reject on your sending domains — this prevents your brand from being spoofed
  • Reject JWT tokens with alg:none — your library may accept them by default
  • Never reflect URL parameters into HTML without sanitization — that’s where XSS lives
  • Add a Content-Security-Policy header that blocks inline script execution

If you’re in a SOC:

  • Create an alert rule for emails where SPF=fail AND DKIM=none AND subject contains urgency keywords
  • Flag JWT tokens in inbound URLs with alg:none in your WAF
  • Hunt for eval(atob( patterns in proxy logs — double-encoded JavaScript is never legitimate traffic

Sources