Cloud IP Laundering: A Red Team Guide to Bypassing Reputation Filters

Your phishing campaign is perfect. The pretext is solid, the payload is elegant, and the domain is a work of art. You fire off the first batch and... nothing. Not a single beacon. A quick check of the gateway logs confirms your fear: '550 5.7.1 Message rejected due to poor reputation of the sending IP address.' The IP was 'clean'—not on a single public blocklist. So what happened?

You got beat by modern heuristics. Security gateways no longer trust an IP just because it isn't explicitly bad. They look for positive proof that it's good. A brand-new IP address, especially from a public cloud provider, is treated as guilty until proven innocent. It has no history, no established traffic patterns, no trust.

This is why sophisticated operators don't just grab a fresh IP. They launder one. They find and cultivate IP addresses with a benign history, warming them up over weeks to build a reputation that makes security tools see a trusted partner, not an ephemeral threat.

Why a 'Clean' IP Is a Red Flag

In the early days of email security, reputation was binary. You were either on a blocklist or you weren't. Today, it's a credit score. Mail Transfer Agents (MTAs) and Secure Email Gateways (SEGs) assign a continuously calculated reputation score to every source IP they see. A fresh IP from an AWS or GCP subnet starts with a score of zero, or even slightly negative.

This isn't just about blocklists anymore. These systems analyze the age of the IP, the reputation of its entire ASN block, its historical traffic volume, and the diversity of its traffic. An IP that was allocated yesterday and immediately starts sending email, even with perfect SPF (RFC 7208) and DKIM (RFC 6376) alignment, screams 'throwaway infrastructure.' It’s the digital equivalent of someone paying for a coffee with a brand-new hundred-dollar bill. It might be real, but it’s suspicious.

A new IP address that has not been seen sending email presents a risk that mail receivers are wary of. Spammers and other malicious actors will frequently switch IP addresses to evade blocklists and poor sending reputations.

This scoring model is precisely what the IP laundering tactic is designed to subvert. The goal isn't just to be 'not bad,' but to be verifiably 'good' before the first malicious email is ever sent.

The IP 'Leasing' Tactic: Acquiring Aged Infrastructure

The foundation of this TTP isn't technical skill; it's patience and resourcefulness. Attackers need IPs that have existed for months or years but have seen little to no malicious traffic. These are not found by port scanning. They are acquired.

Hunting for Dormant Accounts

The primary source is dormant cloud accounts. Think of a startup that failed, a skunkworks project that was abandoned, or a developer who moved on. These AWS, Azure, or GCP accounts might have Elastic IPs, reserved virtual machine instances, or entire subnets that were allocated long ago. They sat unused, accumulating nothing but age. This age is the critical asset.

Attackers can acquire these accounts through various means: credential stuffing attacks against the cloud provider's login portal, purchasing them from underground marketplaces, or by phishing the original owners. In some cases, operators will simply register hundreds of accounts and let them sit idle for a year, creating their own 'farm' of aged assets for future campaigns.

Beyond the Big Three

While the major cloud providers are prime targets, the same logic applies to any service that allocates dedicated IPs. This includes smaller VPS providers, dedicated hosting companies, and even compromised IoT devices that have a static public IP. Any IP with a history that is not associated with spam is a potential candidate for laundering.

Pre-Flight Check: Vetting Your Acquired IP

Once you have control of an aged IP, the work is just beginning. Using it blindly is a recipe for failure. A thorough pre-flight check is mandatory to ensure the asset is as valuable as it appears.

Forensics on Your Own Asset

First, the basics. Run the IP through every major public blocklist (Spamhaus, SURBL, SORBS, etc.). A hit on any of them makes the IP worthless for email campaigns. But that's just step one. The real analysis is historical. Use passive DNS and IP intelligence tools to see what domains have pointed to this IP in the past. Check the reputation of the parent /24 subnet and the broader ASN. An IP might be clean, but if it lives in a 'bad neighborhood' known for hosting C2 infrastructure or malware, it's tainted by association.

You also need to check for provider-specific issues. Does the AWS account have its port 25 throttle removed? Some older accounts do by default, which is a massive bonus. Are there any outstanding abuse complaints tied to the account ID itself? A single past violation can flag the entire account for heightened scrutiny, rendering your warming efforts useless.

Authentication-Results: mx.google.com; spf=pass (google.com: domain of operator@example.com designates 34.212.X.X as permitted sender) smtp.mailfrom=operator@example.com; dkim=pass header.i=@example.com; — A sample 'Authentication-Results' header showing successful SPF and DKIM validation.

Finally, set up basic DNS hygiene immediately. Create a PTR record that resolves back to a plausible hostname. This reverse DNS lookup is a simple but powerful check that many gateways perform. An IP without a valid PTR is an immediate red flag.

The Slow Drip: Simulating Benign Activity

This is the most critical and time-consuming phase. The goal is to transform the IP from 'unknown' to 'trusted' in the eyes of services like Gmail and Microsoft 365. You can't rush it.

Building a Legend

Start by setting up a legitimate-looking domain and configure its mail authentication records perfectly. SPF must be a hard pass, not a softfail. DKIM signatures must be correctly implemented, protecting against transit modifications that could cause a body hash mismatch. A DMARC record (RFC 7489) set to `p=none` is essential; it signals that you are monitoring authentication without yet enforcing it, which is typical for a new domain.

Then, begin sending email. Not phishing email. Benign email. Send newsletters, account notifications, and simple text-based messages from your warm-up IP to accounts you control across all major providers. The volume must be extremely low initially—think 10-20 messages per day. Open these emails. Click links in them. Reply to them. Mark them as 'Important'. These interactions are positive signals that tell the receiver's algorithms that humans are engaging with this mail, building your reputation score.

The Patience Game

Over several weeks, slowly and predictably increase the volume. Any sudden, exponential spike will trigger alarms and can erase weeks of patient effort. The traffic should also look diverse. Send to different providers, not just one. Mix in some traffic on other ports, like HTTPS, to make the server look like a real, multi-purpose machine, not just a disposable spam cannon.

This process systematically moves your IP's reputation from a neutral/unknown state to a positive one. By the end of the warm-up period, which can take anywhere from three to eight weeks, the IP is no longer a liability. It's a key that can unlock the inbox.

Weaponization and Defense

Red Team: Pivoting from Warm to Hot

With a fully warmed IP, it's time to launch. But even now, restraint is key. Don't use your prized asset for the entire attack chain. The warm IP's job is to get the initial email past the SEG. This is for delivering the link or the initial stage-one dropper. The user clicks, and the subsequent C2 traffic should be directed to different, more disposable infrastructure. Burning a warm IP on post-exploitation traffic is a waste of a valuable asset.

The ramp-up in volume should continue to be gradual. Blend your malicious sends in with the ongoing benign traffic. Instead of blasting 10,000 emails at once, send them in smaller batches over several hours or days. This makes the campaign harder to distinguish from a legitimate, albeit growing, marketing effort.

Blue Team: Detecting the Unseen

Defending against this is not about blocking cloud provider IP ranges—that's a losing battle. The key is to hunt for behavioral anomalies. Your log data holds the clues. Look for IPs that have been part of your environment for a long time but have a historical mail volume of zero. If one suddenly starts sending email, even with perfect authentication and low volume, it demands investigation.

event_time=..., action=permit, src_ip=52.90.X.X, mail_from=..., hist_daily_avg_vol=0, curr_daily_vol=50, spf_result=pass, dkim_result=pass, dmarc_result=none — A hypothetical log entry showing a dormant IP suddenly becoming active.

Monitor DNS transparency logs for newly registered SPF and DKIM records pointing to long-dormant IPs. Correlate email gateway logs with network flow logs. An IP that *only* speaks SMTP and has no associated web traffic is anomalous. Real mail servers are often part of a broader infrastructure. This multi-layered visibility is critical for spotting the slow-drip warm-up before it becomes a full-blown attack.

The takeaway

The fight for the inbox is increasingly fought on the battlefield of reputation. Static, signature-based defenses are simply not enough. Red teams know that a patient, methodical approach to building a sender's reputation can bypass multi-million dollar security stacks. For defenders, this means shifting focus from simple 'block/allow' decisions to time-series analysis of sender behavior.

You have to ask not only 'Is this IP bad right now?' but also 'Was this IP doing anything last week? Last month?' Spotting a dormant IP that suddenly wakes up and starts trying to make friends is one of the strongest indicators of a looming, sophisticated phishing campaign. Platforms that can analyze historical email data, like MailSleuth.AI, provide the context needed to connect these dots before the attack lands.