The ASN Red Flag: Why an IP's Neighborhood Is a Key Phishing Indicator

An urgent wire transfer request from your CFO hits a VP's inbox. The branding is perfect. The domain is correct. You pull up the headers and your security gateway gives it a clean bill of health: SPF `pass`, DKIM `pass`, DMARC `pass`. Yet, something feels off. The request is just unusual enough to trigger your analyst's intuition.

The sending IP address geolocates to a plausible region—nothing obviously suspicious there. But then you look one level deeper. You check the IP's Autonomous System Number (ASN). It belongs to a budget cloud hosting provider in Germany known for short-term server rentals. Your company's mail flows through Microsoft 365. Your CFO has never sent an email from a 5-dollar burner server.Suddenly, a passing DMARC verdict doesn't feel so reassuring.

This is the reality of modern email attacks. Threat actors aren't just spoofing domains; they're exploiting legitimate, authenticated infrastructure. In this landscape, the ASN isn't just a piece of metadata. It's the digital neighborhood of the sending server, and it's one of the most potent, context-rich signals for exposing sophisticated fraud.

The Internet's Neighborhood Watch

Too many analysts stop their IP investigation at GeoIP. Seeing an email from a US company originate in the US feels like a validation. It's a low-value signal. An IP address is just a house number. What's far more important is the neighborhood it's in. That's the ASN.

An Autonomous System (AS) is a large network or group of networks with a single, unified routing policy. Each AS is assigned a unique ASN by a regional registry. Think of it this way: Microsoft runs its own massive network (AS8075), Google has its own (AS15169), and your home internet provider has its own (like AS7922 for Comcast). These are distinct, well-known digital territories.

Trust Is Transitive

Why does this matter for email forensics? Because trust is transitive. An email from `paypal.com` should originate from an IP address within PayPal's or their partners' known ASNs. If it arrives from an IP in AS14061 (DigitalOcean) or AS16276 (OVH), something is deeply wrong, even if the authentication checks out.

These hosting providers are not inherently malicious, but they are commodity infrastructure. They're the equivalent of a massive industrial park filled with thousands of anonymous, short-term rental units. Attackers love them for exactly this reason: they can spin up a server, blast a phishing campaign, and disappear in minutes. An email from your bank should come from the bank's well-fortified corporate campus, not a temporary warehouse unit.

Anatomy of a 'Passing' BEC Attack

Let's deconstruct a common Business Email Compromise (BEC) scenario. The attacker isn't using a lookalike domain like `acme-corp.co`. They're sending from the actual `acme.com` domain. How? They've found a legitimate third-party service that Acme Corp has authorized to send emails on its behalf.

Imagine Acme Corp uses a marketing platform to send newsletters. To make this work, the IT admin added an `include:send.marketingplatform.com` mechanism to Acme's SPF record (defined in RFC 7208). This tells receiving mail servers, "Any mail from an IP address approved by `send.marketingplatform.com` is legitimate."

The threat actor signs up for a free trial of that same marketing platform. Because the platform's own SPF record is permissive enough to include all its sending servers—including the new one the attacker just provisioned—the attacker can now send an email as `ceo@acme.com` that results in a perfect `pass` on SPF and, consequently, DMARC (specified in RFC 7489). Your gateway sees this and waves it through.

Received: from mail-server-123.some-cloud.host (HELO vm-45-67.attacker.net) (45.55.55.67) by mx.google.com with ESMTPS; Authentication-Results: mx.google.com; dkim=pass header.i=@acme.com; spf=pass (google.com: domain of ceo@acme.com designates 45.55.55.67 as permitted sender) smtp.mailfrom=ceo@acme.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=acme.com

The header above looks clean. The verdicts are all `pass`. But the sending IP, `45.55.55.67`, is the thread to pull. A quick `whois` lookup on that IP reveals it belongs to an ASN like DIGITALOCEAN-ASN. This is the mismatch. The email claims to be from Acme Corp, and it technically passes authentication via a trusted third party, but it originates from a server in a neighborhood that has no business relationship with Acme's core operations.

A Triage Workflow for ASN Mismatches

You can't rely on gut feelings. You need a repeatable process to identify a suspicious email ASN mismatch. This is a core part of any serious email threat investigation.

Step 1: Find the True Sending IP

Start by analyzing the `Received` headers, reading from the bottom of the header block upwards. You are looking for the first hop from an external, untrusted server into your environment (or into a major provider like Google or Microsoft). This IP address is your prime suspect. Ignore the internal hops within your own mail infrastructure.

Step 2: Identify the Sending ASN

Once you have the IP, use a command-line tool like `whois` (`whois 45.55.55.67`) or an online portal. You're not just looking for the owner's name; you're looking for the 'OriginAS' or 'ASN' field. This gives you the number (e.g., `14061`) and the handle (e.g., `DIGITALOCEAN-ASN`). Document both.

Step 3: Profile the Domain's Known Infrastructure

This is the critical cross-referencing step. You need to build a picture of where the `From` domain's email is *supposed* to come from. Use DNS query tools like `dig` or `nslookup`.

First, check the domain's MX records (`dig mx acme.com`). This tells you where inbound mail is handled. Often, it's a major provider like `acme-com.mail.protection.outlook.com`. Run `whois` on the IPs of these servers to find their ASNs (e.g., Microsoft's AS8075). Now, check the domain's SPF record (`dig txt acme.com`). Recursively resolve every `include:` mechanism. If you see `include:_spf.google.com` or `include:mail.salesforce.com`, you need to find the ASNs for Google and Salesforce's mail servers, too. Compile a list of these 'approved' ASNs.

Finally, compare. Is the ASN of the actual sending IP from Step 2 on your list of approved ASNs from Step 3? If the answer is no, you have a high-confidence indicator of an attack. This is the smoking gun an email ASN mismatch provides.

From Alert to Blocklist: Creating Durable Detections

Manual triage is essential for investigation, but it doesn't scale. The real goal is to use these insights to build more intelligent, automated defenses. Simply blocking every ASN that hosts a phish is a terrible idea—you'd end up blocking huge chunks of AWS and Azure, causing massive collateral damage.

The power lies in creating conditional rules that use the ASN as a contextual layer on top of standard authentication. A mature detection rule doesn't just say `BLOCK ASN 14061`. It says something much more specific:

IF header.from domain is in {high_value_partner_domains} AND sending_ASN is in {untrusted_hosting_asns} THEN raise severity to 'Critical' and quarantine.

This approach allows you to be surgically precise. You're building a profile of what 'normal' looks like for your organization and your key partners. Normal is your own ASN, your cloud provider's ASN (Microsoft, Google), and the ASNs of major SaaS vendors you use (Salesforce, Workday). Anything else should be treated with extreme suspicion, especially for emails from high-value targets like executives or finance departments.

Maintaining these lists of 'good' and 'bad' ASNs requires effort, but it pays dividends. It's a way to codify your organization's digital footprint and instantly spot senders that don't belong, shutting down attacks that sail right through filters relying solely on DMARC verdicts.

Profiling the Usual Suspects

While any network can be abused, a disproportionate amount of phishing and spam originates from a handful of ASNs belonging to large, automated hosting providers. As an analyst, you'll start to recognize them on sight.

Commonly abused ASNs include AS14061 (DigitalOcean), AS16276 (OVH), AS20473 (Choopa, LLC / Vultr), AS63949 (Linode), and AS24940 (Hetzner Online GmbH). This isn't an indictment of these companies' security practices. It's a reflection of their business model: providing low-cost, API-driven, and often anonymous server infrastructure at massive scale.

Attackers exploit this model for its ephemerality. They can programmatically spin up a virtual server for a few cents an hour, execute their campaign, and destroy the server before it accumulates a bad reputation. Their IPs are constantly changing, making simple IP-based blocklists ineffective. The constant factor is the ASN. The infrastructure is disposable, but it's almost always disposable infrastructure rented from one of these major players.

When you see an email from a Fortune 500 company's domain originating from one of these ASNs, your alarm bells should be ringing. It's the digital equivalent of a CEO sending a wire request via a postcard mailed from a random P.O. box. The medium doesn't match the message, and that context is everything.

Putting It All Together

Email authentication standards like SPF, DKIM (RFC 6376), and DMARC have dramatically raised the bar for attackers. But they are not a panacea. They validate *authenticity*, not *intent* or *context*. A passing DMARC check simply confirms that the email is authorized by the domain's policy; it doesn't confirm the email is legitimate or safe.

Even more advanced standards like ARC (RFC 8617), which preserves authentication results across forwarding hops, can't solve this context problem. The attacker sending from a legitimate-but-abused platform is not a chain-of-custody issue; it's an origin issue.

The ASN provides that missing layer of context. It helps you answer a more important question: not just *is this email authenticated?* but *does it make sense for this sender to be using this network?* When the answer is no, you've likely found a phish that your other defenses missed.

The takeaway

Stop treating every `dmarc=pass` as a sign of safety. The most convincing attacks don't break authentication; they exploit it. By integrating ASN analysis into your triage workflow, you shift from a purely technical check to a contextual investigation. You learn to recognize the digital neighborhoods of the internet and spot when a sender is operating from the wrong side of the tracks.

This level of cross-referencing—comparing a sending IP's ASN against a domain's entire known mail ecosystem—is the kind of deep analysis needed to catch today's threats. It requires diligence, but it's how you move ahead of attackers who have mastered the art of hiding in plain sight. For security teams looking to automate this process, platforms like MailSleuth.AI are designed to perform this contextual correlation on every single message, flagging the ASN mismatches that signal a brewing attack.