Beyond RBLs: The Red Team Playbook for Vetting Phishing IPs

Your brand-new phishing domain is ready. You’ve aged it for weeks. But the moment you point it to your Vultr instance and send the first email, it’s dead on arrival. Blocked. Why? Because security teams don't just block domains; they block entire network neighborhoods.

This is the first lesson every aspiring red teamer learns about email delivery. The most cleverly crafted lure, the most convincing landing page—it's all worthless if the receiving mail server slams the door on your SMTP connection. Too many operators focus solely on domain reputation and email content. They miss the foundational layer: the sending IP address.

Sophisticated attackers don't just grab the cheapest VPS and hope for the best. They engage in rigorous, multi-faceted vetting of their sending infrastructure. They act like paranoid system administrators, using the same tools defenders do, but in reverse. They aren't looking for just any IP; they're looking for the *right* IP.

The Initial Recon: Provider History, ASN, and IP 'Age'

The search for a viable phishing IP starts long before a single packet is sent. It begins with reconnaissance on the providers themselves. Not all hosting is created equal, especially in the shadier corners of the internet.

Provider and ASN Forensics

The term 'bulletproof hosting' is a misnomer. Nothing is truly bulletproof. It typically refers to providers with lax acceptable use policies and a high tolerance for abuse complaints. But even within this ecosystem, there's a pecking order. An attacker will investigate a provider's history. Do their network peers frequently drop them? Have their IP ranges been blackholed at the BGP level? The goal isn't necessarily to find a 'clean' provider, but to understand its reputation profile.

This audit extends to the Autonomous System Number (ASN). Security teams with enough operational pain will block entire ASNs known for hosting Command and Control (C2) servers or spam operations. For an attacker, picking an IP from a globally reviled ASN is an immediate dead end. They'll use public BGP toolkits and reputation services to check if an ASN is a known pariah before they ever commit to a server rental.

IP 'Age' and Past Sins

Once a promising provider and ASN are identified, the focus shifts to individual IPs. Like used cars, IPs have a history. An attacker needs to know what a specific IP address was used for before they acquired it. Was it a high-volume mail server that got blacklisted? A TOR exit node? Or, ideally, was it sitting unused in the provider's free pool for months?

Passive DNS and threat intelligence databases are the tools of choice here. By querying an IP's history, an operator can see every domain that has ever resolved to it. An IP with a long, sordid history of hosting malware domains is a liability. The ideal candidate is a 'virgin' IP with no prior record, or one that was last associated with a benign, low-traffic service.

Weaponizing Reputation Tools

Defenders build and maintain a massive arsenal of reputation lists. Real-time Blackhole Lists (RBLs), URI blocklists, and threat feeds are the backbone of modern email filtering. For an attacker, these aren't obstacles; they're a quality assurance checklist.

Before leasing an IP, an operator will run it through every major public RBL provider: Spamhaus, SORBS, SpamCop, Barracuda's BRBL, and others. The goal isn't just to find an IP that is not *currently* listed. The goal is to find one that has a minimal history of ever *being* listed. Some RBLs have a 'memory' and an IP that frequently gets listed and delisted is treated with higher suspicion by mail gateways.

postfix/smtpd[12345]: NOQUEUE: reject: RCPT from unknown[198.51.100.55]: 554 5.7.1 Service unavailable; Client host [198.51.100.55] blocked using zen.spamhaus.org;

The log line above is the attacker's worst-case scenario. The connection is dropped before the `DATA` command, before the email body or headers are even transmitted. The SPF record (RFC 7208) and DKIM signature (RFC 6376) are irrelevant. The IP itself was the single point of failure. This is why pre-flight checks against RBLs are non-negotiable for any serious campaign.

The 'Lookalike ASN' Tactic: Blending In

Bypassing explicit blocklists is just the first step. The next hurdle is heuristic and behavioral analysis. This is where the most meticulous attackers separate themselves. It's not enough to be 'not bad'; you have to look 'normal'.

Imagine a phishing campaign spoofing a major US financial institution. An email notification about a suspicious login is far more credible if it originates from an IP address that looks like it belongs in the United States. An attacker might specifically seek out a VPS or dedicated server from a provider whose ASN is geolocated to the same country as the brand they are impersonating. An email from `bofa.com` originating from an ASN in Virginia is simply less anomalous than one from an ASN in Romania.

This tactic subverts a common layer of automated and human analysis. SOC analysts are trained to spot inconsistencies. When triaging a phish, seeing the `Received` headers trace back to an unexpected country or a notorious 'bulletproof' ASN is a quick win. By matching the origin ASN to the target's geography, the attacker removes that low-hanging fruit, forcing the analyst to look deeper.

The goal is to look boring. By using an IP from a common business hosting provider in the right country, the phish blends in with the millions of legitimate transactional emails sent every day. The IP becomes 'guilty by association' with legitimate traffic, making it harder for automated filters to assign a high-risk score.

Dodging the 'Datacenter' Label

Even an IP with a pristine reputation can carry a stigma. Major email providers like Google and Microsoft are inherently suspicious of mail originating from known datacenter IP ranges. Why? Because while legitimate businesses use them, so does nearly every spammer on the planet. The signal-to-noise ratio is terrible.

Datacenter vs. Residential IP Trust

An IP address from AWS, Azure, GCP, or DigitalOcean screams 'automated service'. It doesn't look like an email sent from a corporate office or a person's device. Mail providers know this. They apply much stricter filtering and rate-limiting to these IP ranges. A brand-new domain sending from a fresh DigitalOcean droplet is one of the most common—and most easily blocked—phishing setups.

This is why attackers covet residential and mobile IP addresses. These IPs belong to consumer-grade ISPs (Comcast, AT&T, Deutsche Telekom) and are assigned to home routers or mobile phones. Mail from these ranges is treated with a different level of trust because it's associated with actual user activity. It's also far noisier, making it harder to pinpoint malicious traffic.

Sourcing and Operational Risk

How do attackers get these IPs? They don't call up Comcast. They use residential proxy networks or malware-infected computers and IoT devices (botnets). By routing their SMTP traffic through a compromised home router in suburban Ohio, their phish appears to originate from a legitimate, non-threatening source. This completely bypasses datacenter-based reputation filtering.

This method carries its own risks. The residential proxy could be slow, unreliable, or get shut down at any moment. But for a high-value campaign, the ability to cloak the origin in a trusted IP block is often worth the operational headache.

The Burn Rate: When to Ditch an IP

No sending IP lasts forever. Once a campaign is detected and reported, the IP's value plummets. It will be added to RBLs, internal blocklists at major companies, and threat intelligence feeds. It is 'burned'. The strategic question for the attacker is how to manage this inevitable decay.

For a 'low-and-slow' campaign, the objective is longevity. The attacker might send a very small number of emails over a long period, staying below the volume-based thresholds that trigger automated defenses. They will carefully warm up the IP, establishing a pattern of legitimate-looking traffic before sending any malicious content. The goal is to keep the IP 'clean' for as long as possible.

Conversely, a 'smash-and-grab' campaign treats IPs as disposable ammunition. The attacker knows the IP will be burned within hours. They will send a massive volume of emails in a short burst, aiming to maximize reach before defenders can react. Once the first `ruf` abuse reports from DMARC (RFC 7489) start rolling in and the IP hits the RBLs, it's discarded and the operation moves to the next IP on the list.

This burn rate calculation is central to an attacker's resource management. Valuable, well-vetted residential IPs are reserved for sophisticated, targeted attacks. Cheap, easily acquired datacenter IPs are used for high-volume, low-effort campaigns where burnout is expected.

Rethinking Your IP Trust Model

IP reputation is a cat-and-mouse game played on a global scale. For every blunt-force ASN block, there's an attacker meticulously searching for a single, clean IP address hiding in a 'trusted' residential subnet. For every RBL, there's an adversary using it as a pre-flight checklist.

Understanding this offensive playbook is critical for building resilient defenses. It shows that relying solely on public blocklists is a losing strategy. Defenders must look at the bigger picture: Is this IP from a datacenter or a residential provider? Does its geographic origin make sense for the purported sender? Has it been 'warmed up' with suspicious but technically non-malicious traffic? You must be able to move beyond a simple pass/fail verdict.

Ultimately, you can't just trust the lists. You have to understand the context and intent behind an IP's behavior. That's where deep header analysis, like the kind MailSleuth.AI performs, becomes critical, allowing you to trace an email's full journey and uncover the subtle anomalies that give away even the most carefully vetted infrastructure.

The takeaway

Thinking like an attacker reveals the fragility of reactive, list-based security. The most dangerous phishing emails aren't the ones that trigger a dozen RBLs; they're the ones that don't trigger any. They come from IPs that look boring, normal, and geographically plausible. Your defense, therefore, can't just be about identifying known-bad infrastructure.

The real challenge is identifying 'anomalous-good' behavior. That requires a shift in mindset and tooling, focusing on the entire chain of transmission—from the source ASN to the `Received` headers—to build a story for every email. Does your current stack allow you to do that?