Adversary Analysis: How Threat Actors Vet Phishing Infrastructure

An alert fires for a generic credential harvesting campaign targeting your finance department. The payload is uninspired, but the delivery mechanics demand a closer look. The sender IP belongs to a reputable cloud provider, the DKIM signature validates perfectly against RFC 6376, and SPF passes without a hitch. The domain was registered three weeks ago and has been entirely dormant until this exact moment.

This is not an accident. It is the result of rigorous pre-campaign vetting. Threat actors treat phishing campaigns like high-stakes marketing rollouts, complete with deliverability testing, A/B testing on security gateways, and meticulous reputation management. By the time that malicious payload hits an inbox, the infrastructure supporting it has already survived a gauntlet of adversarial quality assurance.

Understanding phishing infrastructure reputation requires looking at the problem from the attacker side of the keyboard. They know defenders rely heavily on static blocklists and historical reputation scores. To bypass those controls, adversaries have built dedicated processes to acquire, vet, and burn IP addresses and domains before security vendors can catch up.

The Infrastructure Trilemma

The first operational decision a threat actor makes is where to anchor their delivery infrastructure. Historically, the playbook called for offshore bulletproof hosting providers who ignored abuse complaints and operated out of non-extradition jurisdictions. That model is failing. Modern secure email gateways implicitly penalize traffic originating from known bulletproof autonomous system numbers. If your mail server sits in a notoriously dirty subnet, you start with a massive deliverability deficit regardless of your authentication alignment.

The Shift to Ephemeral Cloud IPs

To secure a neutral starting reputation, attackers pivot to mainstream cloud infrastructure. By spinning up virtual private servers on major hosting providers, adversaries inherit the ambient trust of those ASN blocks. The IPs are theoretically clean, often recycled from legitimate businesses that churned their cloud instances. But this approach introduces a severe operational constraint. Mainstream providers have zero tolerance for abuse complaints. A single validated Spamhaus listing or outbound spam report can trigger an automated takedown of the instance within hours.

Validating the Clean Slate

Acquiring a cloud IP does not guarantee a clean sender reputation. IP addresses are recycled continuously. An attacker might spin up a server only to inherit an IP previously burned by a cryptocurrency botnet or a spray-and-pray spammer. Before pointing DNS records at a new server, operators systematically vet their assigned IPs against public and private blocklist checkers.

This reconnaissance phase relies heavily on querying major reputation clearinghouses. Threat actors script automated checks against Spamhaus ZEN, the Composite Blocking List, and the Barracuda Reputation Block List. If the IP returns a positive hit, the attacker destroys the cloud instance and spins up a new one to roll the dice on a fresh IP. They will repeat this infrastructure churn until they secure an address with zero historical baggage.

Received: from mail.ephemeral-cloud-sender.net (mail.ephemeral-cloud-sender.net. [198.51.100.24]) by mx.target-org.com with ESMTPS id xyz123 for <victim@target-org.com>; (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256) — Typical ingress log highlighting a freshly vetted, high-reputation IP

You can sometimes spot this behavior in DNS query logs if you monitor the infrastructure surrounding suspicious domains. The actor registers a domain, parks it, and then over the next few days, you might see rapid A record updates pointing to different IPs as they test and discard infrastructure that fails their internal vetting.

Evading URI Blocklists

Securing a clean delivery IP is only half the battle. If the email contains a link to a credential harvesting page, that destination domain faces its own reputation gauntlet. Defenders rely on URI blocklists like SURBL and the Spamhaus Domain Block List to catch malicious links regardless of where the email originated. A pristine sender IP means nothing if the payload URL is already flagged.

Domain Chaining and Redirection

To bypass URI blocklists, attackers decouple their delivery infrastructure from their payload hosting. They register disposable domains exclusively for redirection. These intermediary domains are vetted just as rigorously as the sender IPs. When a campaign launches, the emails contain links to the freshly vetted intermediary, which then issues a 302 redirect to the actual backend phishing site. Once the intermediary domain lands on the Spamhaus DBL, the attacker rotates the link in their subsequent email batches, leaving the sender IP and the backend infrastructure untouched.

The Warm-Up Illusion

A common misconception is that threat actors meticulously warm up their phishing domains by sending low volumes of benign traffic over several weeks. While some sophisticated espionage groups use this tactic for highly targeted spear-phishing, it does not scale for financially motivated cybercrime. Genuine domain warm-up requires time, reciprocal communication, and organic engagement to build a sender reputation.

Instead of true warm-up, most attackers attempt to spoof the appearance of age. They buy aged domains that have been parked or expired, hoping the registration date will bypass filters that automatically quarantine newly observed domains. However, modern reputation engines evaluate temporal volume, not just registration age. An aged domain that suddenly spikes from zero outbound messages to thousands per hour triggers aggressive rate limiting and immediate re-evaluation. The sudden velocity change is a dead giveaway, overriding the illusion of established reputation.

Burn Rates and Infrastructure Pivoting

Phishing infrastructure has an incredibly short half-life. Threat actors operate under the assumption that their IPs and domains will be burned. The objective is not to evade detection forever, but to widen the window of deliverability just long enough to achieve an acceptable compromise rate. This requires automated lifecycle management.

Telemetry-Driven Abandonment

Attackers actively monitor their own campaign telemetry. They seed their target lists with canary addresses they control to test inbox placement. If a canary address sees a message land in the spam folder, or if the attacker observes a spike in SMTP 5xx bounce codes indicating blocklist rejection, they trigger their pivot protocols. The flagged IP is abandoned, DNS records are flipped via automated APIs, and the campaign resumes from a standby node that was pre-vetted during the reconnaissance phase.

Rethinking Defensive Telemetry

Understanding this infrastructure lifecycle changes how SOC analysts should approach email forensics. Do not fixate solely on the sender IP. Threat actors view IPs as disposable ammunition. Instead, analyze the connective tissue between the delivery node and the payload. Look for rapid DNS TTL changes, track the intermediary redirection domains, and monitor for sudden volume spikes from historically dormant infrastructure.

Defensive architecture must prioritize behavioral heuristics over static reputation. If your gateway allows an email through just because the IP is clean today, you are falling for the exact trap the adversary designed. Correlate temporal anomalies, enforce strict age-based quarantine policies for unrecognized sender domains, and use platforms like MailSleuth.AI to map out the broader infrastructure clusters before the adversary has a chance to pivot.

The takeaway

The arms race between offensive deliverability and defensive reputation scoring is entirely asymmetric. Attackers can burn through infrastructure faster than traditional blocklists can update. To win this fight, security teams must stop treating domains and IPs as static indicators of compromise and start treating them as temporal artifacts.

Are your detection rules tuned to catch the velocity of infrastructure change, or are you just waiting for someone else to flag the IP first?