Beyond the Last Hop: Tracing Phishing Through VPNs and Proxies

You’re staring at an urgent wire transfer request from your CFO. The grammar is perfect, the tone is right, and all the email authentication checks—SPF, DKIM, DMARC—are passing with flying colors. But something feels off. The request is unusual, and the pressure is high. This is the new face of business email compromise, and the clues to unraveling it aren't in the message body.

Threat actors are masters of camouflage. They've largely abandoned noisy, easily-blocked IP addresses for the sterile, high-reputation environments of public cloud platforms and consumer VPN services. They know that your security stack is hesitant to block an IP range belonging to Amazon or Google, because it might disrupt legitimate business traffic.

This is an operational blind spot for many security teams. Attackers are exploiting the trust we place in big tech infrastructure to launder their malicious traffic. To catch them, you have to look past the superficial authentication results and trace the email's true path through the internet's plumbing: the `Received` headers.

Why Your Blocklist Can't Keep Up

The days of blocking a threat actor's sketchy residential IP are over. It was too easy, too definitive. The modern adversary understands that infrastructure is disposable and reputation is rentable. For the price of a coffee, they can spin up a virtual machine on any major cloud provider or route their traffic through a commercial VPN service with thousands of exit nodes.

The High-Reputation Shell Game

These IPs come from enormous, legitimate network blocks. Blocking a single IP is a game of whack-a-mole, and blocking the entire subnet of a provider like DigitalOcean or Hetzner would cause a self-inflicted denial-of-service. Attackers use this to their advantage. They operate from within a trusted space, knowing their initial connection is unlikely to trigger alarms based on IP reputation alone.

This creates a nasty overlap. A credential harvesting email might originate from the same AWS IP block as your company's own marketing platform. A BEC attempt might come from the same VPN provider an employee uses to work from a coffee shop. Traditional IP-based security filters struggle to make a judgment call without more context.

Your First Clue: The Received Header Trail

Every email carries its own travelogue. The stack of `Received` headers in the raw email source shows every Mail Transfer Agent (MTA) that handled the message, starting from the sender and ending in your inbox. Unlike the `From` address, which is as forgeable as a return address on a physical envelope, the `Received` trail is a factual record of the email's journey across servers.

We read these headers from bottom to top. Your target is the *first* (bottom-most) `Received` header added by an external, trusted MTA—like Microsoft 365 or Google Workspace. This header documents the jump from the attacker's system into the legitimate email ecosystem. The IP address captured here is your starting point.

Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51])
by mx.example.com with ESMTPS id abc123def456;
Tue, 28 May 2024 11:45:10 -0400
Received: by mail-pj1-f51.google.com with SMTP id h19so123456pjh.1
for <victim@example.com>; Tue, 28 May 2024 08:45:09 -0700 (PDT)
Received: from [203.0.113.78] (unknown [203.0.113.78])
by smtp.gmail.com with ESMTPSA id i5sm654321pfa.47.2024.05.28.08.45.08
for <victim@example.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);

In the chain above, the last `Received` header is the most interesting. It shows that Google's SMTP server accepted a connection from the IP address `203.0.113.78`. The higher headers just detail the email's subsequent path inside Google's network and on to the recipient's mail exchanger. That first IP is our patient zero.

What Is This IP, Really?

Once you have the originating IP, the real analysis begins. Simply plugging it into a geo-lookup tool is analyst malpractice. The reported city or country is often wildly inaccurate for dynamic or cloud-based IPs. What matters isn't where the IP is, but *what* it is. The Autonomous System Number (ASN) and the organization that owns the netblock are far more telling.

The ASN Mismatch Heuristic

This is the core of the technique: compare the infrastructure to the claimed identity. An email pretending to be from your partner company, "Global Logistics Inc.," should probably originate from their corporate email gateway or a major service like Microsoft 365. If the originating IP's ASN is something like "ASN-CHOOPA" (Vultr) or "M247-LTD" (a known host for VPNs), you have a significant anomaly. Legitimate businesses don't typically send corporate email directly from a bare cloud VM in a random datacenter.

Use IP intelligence services—some are free, others are part of broader threat intel platforms—to classify the IP. These tools can often tell you directly if an IP is associated with a 'Hosting Provider', 'Consumer VPN', 'Tor Exit Node', or 'Public Proxy'. Seeing an email from 'd.smith@your-bank.com' originating from an IP flagged as 'Consumer VPN' should set off every alarm bell you have.

Connecting the Dots for a Full Narrative

A suspicious IP is a powerful signal, but it's just one piece of the puzzle. Effective incident response is about building a coherent story by correlating multiple data points. A single indicator can be a false positive; a cluster of related indicators is an attack.

Start pivoting. Has this same IP address from the VPN provider sent other emails to your organization? What about the sender domain in the `From` header? Check its WHOIS registration date. A domain created yesterday, sending emails via a generic cloud server IP, is practically a confession. These 'Newly Registered Domains' (NRDs) are a staple of phishing campaigns.

An IP address tells you where an email came from. The ASN tells you what it came from. The payload tells you why it was sent. You need all three to build a case. — A grizzled IR veteran

Finally, examine the payload. Does the URL in the email body lead to a landing page hosted in the same ASN as the sending IP? Threat actors often use the same provider for both their mail sending and their phishing sites. Finding this connection strengthens your conclusion that the activity is coordinated and malicious, not just an odd, one-off event.

From Manual Triage to Automated Defense

Digging through headers for every suspicious email doesn't scale. The ultimate goal is to translate these manual investigative steps into automated heuristics for your secure email gateway or SOAR platform. You want the machine to flag these anomalies, so your analysts only focus on the highest-risk events.

Building Risk-Scoring Rules

Think in terms of a risk score rather than a simple block/allow decision. A rule could look like this: IF the originating IP is classified as 'VPN' or 'Hosting' AND the sender domain was registered less than 60 days ago, THEN add 50 points to the message's spam score and hold it for review. This is far more effective than a blunt rule like `BLOCK ALL FROM ASN-DIGITALOCEAN`.

The key is combining factors. An email from a new domain is slightly suspicious. An email from a generic cloud IP is slightly suspicious. An email from a new domain, originating from a generic cloud IP, that also fails DMARC alignment? That's not suspicious; that's hostile. Your rules should reflect this multiplicative risk.

Why DMARC Alone Isn't Enough

It's critical to understand the limits of standard authentication. An attacker can use a legitimate, DMARC-compliant mail service to send their phish. They create an account at a small email provider, set up SPF (RFC 7208) and DKIM (RFC 6376) correctly for their malicious domain, and send away. The receiving server sees valid authentication and a passing DMARC (RFC 7489) result. This is 'passing' in a technical sense, but it completely misses the intent. The `Received` header analysis closes this gap, asking the one question DMARC doesn't: who is the user authenticating to this 'legitimate' service in the first place?

The takeaway

The battleground for email security has shifted. It's no longer about identifying obviously 'bad' infrastructure but about detecting legitimate infrastructure used for malicious ends. The signals are more subtle, buried in metadata that most email clients and even some security tools ignore by default.

Stop taking a passing DMARC verdict as a sign of absolute safety. The `Received` header is your source of truth. By analyzing the originating IP, its ASN, and its classification, you can expose the critical mismatch between a sender's claimed identity and their operational infrastructure. This context is everything. It's the difference between catching a sophisticated attack in progress and explaining a financial loss to your board, and it's why having a platform like MailSleuth.AI to surface these insights automatically is no longer a luxury, but a necessity.