There is a suspicious email from Paypal
A German-language message arrived under a spoofed PayPal display name, sent from an unrelated domain. Its return path pointed at a throwaway bounce address on a different domain again, and the SPF check passed for the sending server, which only proves the server was allowed to send for the envelope domain, not that the mail was PayPal’s. The call to action was a link into a public Google cloud storage bucket, a trusted domain used to host the credential-harvesting page and slip past reputation filters. Every verdict comes from the headers and the HTML body of one .eml file.
paypal.eml → open as plain text; headers at the top, HTML body below. grep is enoughThe Return-Path header holds the envelope sender, the address bounces go to. Pull it directly and compare it with the visible From: line. It belongs to a different domain than the display name suggests, which is the first mismatch.
grep -i '^Return-Path' paypal.emlThe lure is in the HTML body, so extract every http(s) URL from it. The link in the call to action points at a Google-owned FQDN, followed by a bucket and object path. Report the FQDN only.
grep -ioE 'https?://[^"<> ]+' paypal.emlFrom Q2 the domain is Google Cloud Storage, which no reputation list will flag. Judge the context instead: a PayPal-branded message has no reason to send a user to someone’s public storage bucket, and anyone can upload a page there. The domain is the host; the bucket content is the attacker’s. This is a judgement call, not something a header proves.
Gotcha: The domain itself is legitimate, so “No” looks right on reputation alone. That answer is rejected. The question is about how the domain is used in this email, not whether Google is trustworthy.
Read the Received-SPF header and take the client-ip= value, the server that handed the message over. The result is pass, but that only validates the sending host against the envelope domain from Q1, so it says nothing in PayPal’s favour.
grep -i 'Received-SPF' paypal.emlTip: Don’t take the IP from a
Received:line; the question wants the one SPF evaluated.
The indicators stack up: a display name spelled P.A.Y.P.A.L to dodge keyword filters, a From domain (kodehexa.net) with no link to PayPal, a return path on a third unrelated domain (Q1), a German-language lure, and a link into an attacker-usable bucket (Q2, Q3). A passing SPF (Q4) doesn’t offset any of it.
grep -iE '^(From|Return-Path|Received-SPF):' paypal.eml| Phase | Action |
|---|---|
| Defense Evasion | Message sent under a spoofed PayPal display name from an unrelated domain |
| Defense Evasion | Envelope sender set to a random bounce address on a third domain |
| Initial Access | German-language lure with a link to a page hosted on Google Cloud Storage |
| Type | Value |
|---|---|
| Return path | [email protected][.]uk[.]com |
| Sending domain | kodehexa[.]net |
| Sending IP (Received-SPF) | 134.195.196[.]43 |
| Link host | storage[.]googleapis[.]com |
| Display name | P.A.Y.P.A.L |
| Technique | ID | Description |
|---|---|---|
| Phishing: Spearphishing Link | T1566.002 | Lure email with a link to a hosted phishing page |
| Impersonation | T1656 | Spoofed PayPal display name |
SPF pass is not sender authenticity. SPF validated the sending IP against the envelope domain, which the attacker owns. Alignment with the visible From domain (DMARC) is the check that would have failed here.
Return-Path, From and display name should agree. Three different identities in one message is a cheap, reliable rule: flag mail where the display name claims a brand the From domain doesn’t own.
Trusted storage domains need content-aware handling. A reputation allowlist for storage.googleapis.com lets the lure through. Treat links to public storage buckets in brand-themed mail as suspicious, or detonate them in a sandbox.
The email carried no malware, only a believable brand name and a link on a domain nobody blocks. The headers gave it away: three mismatched identities and an SPF pass that proved nothing.