The Red Teamer’s IP Warm-Up Playbook: How Attackers Vet Infrastructure

Your meticulously crafted phish, complete with a clever pretext and a pixel-perfect landing page, just landed in the spam folder. The domain was new but clean. The email content passed the NLP scanners. So what happened? Your IP address was garbage. It was tainted from the moment you leased it.

Sophisticated attackers and red teams know that successful campaigns are built on a foundation of clean infrastructure. The operational security (OPSEC) that goes into selecting, vetting, and warming up an IP address is a critical, often-overlooked phase of the attack lifecycle. A bad IP sinks a campaign before the first email is even sent. A good IP makes deliverability almost a foregone conclusion.

This is the playbook they use. For defenders, understanding these tactics is the first step toward recognizing a patient, methodical adversary and building detections that look beyond a simple blocklist lookup.

Goal #1: Evade the 'Guilty by Association' Taint

Getting an IP that isn't on a Real-time Blackhole List (RBL) is table stakes. That's amateur hour. The real game is avoiding entire network neighborhoods known for abuse. Attackers know that security filters don't just judge an individual IP; they judge the Autonomous System Number (ASN) and the broader Class C block (/24) it belongs to.

Reconnaissance of IP Blocks and Hosting Providers

Before leasing a single virtual server, an operator will perform reconnaissance on the hosting provider itself. They’re looking for a provider that occupies a 'Goldilocks zone'—not a top-tier cloud provider whose IPs are heavily scrutinized, but also not a 'bulletproof' host in a sketchy jurisdiction that mail gateways block on sight. They want a mid-tier VPS provider that hosts thousands of small businesses.

The goal is to blend in. Using simple `whois` lookups and public IP intelligence tools, they assess the provider's IP ranges. Are other IPs in this /24 block associated with spam or malware? Does the ASN have a history of harboring bad actors? A provider with a high concentration of IPs on the Spamhaus Policy Block List (PBL)—which often includes dynamic or residential ranges unsuitable for mail servers—is an immediate red flag. The attacker is actively trying to select an IP address whose neighbors are boringly legitimate.

Post-Acquisition Burn-In: Checking for Latent History

Once an attacker leases a server, the clock starts. But they don't start building the phishing kit. First, they check for ghosts. An IP address can have a long and sordid history, and email filters have very long memories.

The first step is a deep blacklist check against not just the major RBLs, but dozens of smaller, regional, or proprietary lists. An IP might be clean on Spamhaus but flagged on a local list in the target's specific country. This check determines if the asset is immediately compromised.

Uncovering an IP's Past Life

More importantly, the operator will use passive DNS (pDNS) databases to query the IP's history. Has this address ever resolved to a domain associated with malware command-and-control (C2)? Was it used in a phishing campaign six months ago? Even if the IP is 'clean' now, many large organizations and security vendors maintain their own internal, historical blocklists. An IP with a bad past is a tainted asset.

If any significant negative history is found, the methodical attacker abandons the IP. They cut their losses, terminate the server, and start the vetting process over. The few dollars lost on the VPS rental is a small price to pay to avoid burning an entire campaign, along with the associated domains and tooling.

The PTR Record: Your IP's Business Card

Few things scream 'illegitimate mail server' louder than a missing or misconfigured reverse DNS (PTR) record. Many mail transfer agents (MTAs) will outright reject mail from an IP that fails this basic check. It’s one of the oldest tricks in the anti-spam book, and competent attackers know how to ace the test.

A generic PTR record, like `12-34-56-78.static.vps-provider.net`, is a dead giveaway that someone just spun up a server and didn't bother with the details. It signals a transient, non-professional setup. Attackers need to establish a plausible identity, and that starts with Forward-Confirmed Reverse DNS (FCrDNS).

This means the PTR record for their IP (e.g., `203.0.113.10`) must resolve to a hostname they control (e.g., `mx1.business-services.io`), and crucially, the A record for that hostname must resolve back to the original IP address. It’s a closed loop of identity. This requires control over both the IP's PTR record settings—often via the VPS provider's control panel—and the domain's DNS zone file.

Authentication-Results: mta.example.net; spf=pass smtp.mailfrom=aggressor.com; dkim=pass (key-1) header.d=aggressor.com; dmarc=pass (p=none) header.from=aggressor.com — Typical Authentication-Results header for a well-configured sender

The hostname itself, `mx1.business-services.io`, is part of the pretext. It sounds like a plausible mail server for a legitimate B2B company. This simple configuration detail is a prerequisite for passing more advanced checks and achieving the coveted `pass` verdicts for SPF (RFC 7208) and DKIM (RFC 6376), which are foundational to DMARC (RFC 7489) alignment.

IP Warm-Up: Manufacturing a Good Reputation

With a clean, well-configured IP address in hand, the campaign can begin, right? Wrong. A brand-new IP that suddenly starts sending hundreds of emails is a five-alarm fire for any modern reputation system. This is where the patient process of 'warming up' the IP begins.

The goal of the warm-up phase is to build a history of benign activity, training the algorithms at major mailbox providers like Google and Microsoft to associate the IP with legitimate mail. An attacker isn't just trying to avoid being marked as 'bad'; they are actively trying to be marked as 'good'.

The Art of the Slow Ramp

The process is methodical. The attacker will configure their mail server to strictly adhere to all best practices: SPF, DKIM, DMARC (`p=none` at first), and a proper PTR record are all in place. Then, they begin sending low volumes of non-malicious email. This might involve subscribing their new sending domain to hundreds of newsletters, which generates legitimate inbound and outbound traffic (like confirmation emails).

They will also send a slowly increasing volume of email from the new IP to a set of seed accounts they control across various providers. They start small: 20-50 emails on day one, then 100 on day two, 250 on day three, and so on. They monitor deliverability to these seed accounts religiously. Are the emails landing in the inbox? The primary spam folder? The promotions tab? This feedback loop dictates the pace of the warm-up. If emails start getting flagged, they slow down or pause the ramp.

This process can take anywhere from a few days to several weeks. It is a deliberate, resource-intensive effort to manufacture a positive sending reputation. By the time the IP is used for the actual phishing campaign, it no longer looks `new`. It looks established.

The takeaway

By the time a well-crafted phish from a methodical attacker reaches your mail gateway, the IP it came from doesn't look 'bad.' In fact, it looks positively pristine. It has no negative history, a plausible reverse DNS entry, and a recent track record of sending low-volume, benign mail that passes all standard authentication checks. Reputation-based filtering, on its own, will fail.

This is why defenders must look deeper. The game isn't just about blocking known-bad infrastructure; it's about spotting the subtle tells of purpose-built, artificially aged infrastructure. Analyzing the entire email header for tiny inconsistencies, like mismatches in the authentication chain revealed by ARC (RFC 8617) or unusual `Received` header syntax, becomes paramount. Tools that perform this deep analysis, like MailSleuth.AI, can help surface the anomalies that betray an attacker who has done everything else right.