The Attacker's Pre-Flight: Building Trust on Phishing Domains

That green 'pass' in the email header feels like a sigh of relief. You see `dmarc=pass`, `spf=pass`, `dkim=pass`, and your tired analyst brain starts to file the email away as legitimate. But it's not. The link leads to a credential harvesting page, and the whole campaign was orchestrated to earn that passing grade. This isn't a failure of the standards; it's a feature of a patient, methodical attacker.

Sophisticated business email compromise (BEC) and phishing campaigns don't start with a freshly registered domain and a spam cannon. They begin weeks or months earlier with a deliberate, painstaking process of building perceived legitimacy. The goal isn't to be bulletproof. It's to be just legitimate enough to sail past automated scanners and land in the inbox, where the only remaining defense is an overworked human.

This is the red teamer's playbook. Understanding it is the first step to dismantling it.

More Than a Domain: The Infrastructure Pre-Flight

The operation begins not with an email, but with a credit card and a plan. The choice of domain registrar and hosting is the first tell. Attackers gravitate toward registrars known for lax oversight and cheap, disposable virtual private servers (VPS). They aren't looking for premium support; they're looking for anonymity and plausible deniability.

Art of the Lookalike

The domain name itself is a critical piece of social engineering. Classic typosquatting—`micros0ft.com` instead of `microsoft.com`—is noisy and often caught by brand protection services. The modern approach is more subtle. An attacker might register `yourcompany-sso.net` when your real domain is `yourcompany.com`. It looks plausible, especially in a long URL string. Another favorite is the use of homoglyphs from other character sets, like using the Cyrillic 'а' instead of the Latin 'a'. To the human eye, they can be identical. To the machine, they are entirely different.

Building a Plausible Façade

A naked IP address or a domain that resolves to nothing is a massive red flag. So, the next step is to give the domain a home. This doesn't require a complex web application. A simple, static HTML page will do. Attackers often rip the public-facing site of a legitimate, unrelated small business and post it on their server. Why? Because when an automated sandbox or a curious analyst visits the domain, they see a real estate agent's contact page or a local plumber's 'About Us'. It's benign, boring, and most importantly, it doesn’t trigger alarms. At the same time, they'll create the necessary DNS records: an A record pointing to their VPS and an MX record to show they're ready to receive mail, even if it just goes to a black hole.

The Waiting Game: Aging Domains into Legitimacy

This is where patience separates the script kiddies from the serious threat actors. A domain registered yesterday and blasting out thousands of emails today is the definition of suspicious. Many reputation filters, from spam gateways to secure email gateways (SEGs), explicitly penalize or block newly registered domains (NRDs). Attackers know this, so they play the long game.

The domain is 'aged' for 30, 60, even 90 days before it's ever used in an attack. During this time, it sits dormant or, for more advanced attackers, engages in completely benign activity. The goal is to build a history—a reputation baseline that looks normal.

Warming Up IPs and Generating Benign History

It's not just the domain's age, but the sending IP's reputation that matters. An attacker will 'warm up' their server's IP address. This involves sending a small, gradually increasing volume of legitimate-seeming email. Think subscribing to newsletters, signing up for accounts on public forums, or sending non-malicious messages between mailboxes they control. This simulates the activity of a new, legitimate mail server coming online and avoids the sudden traffic spikes that alert reputation systems.

This activity gets the domain and IP indexed. It gets crawled by search engines. It might even get categorized by web filters as 'business' or 'uncategorized'—anything other than 'malicious'. By the time the domain is weaponized, it has a digital footprint that looks clean.

Just Enough to Pass: The Art of Minimalist Email Authentication

Here's the counter-intuitive part for many defenders: attackers love email authentication. SPF, DKIM, and DMARC aren't obstacles; they're camouflage. An attacker's goal isn't to create a perfectly compliant, secure email setup. It's to do the bare minimum required to get a `pass` verdict in the `Authentication-Results` header.

SPF, DKIM, and the `p=none` Play

For Sender Policy Framework (RFC 7208), they'll create a simple TXT record. Often, they'll use a `~all` (softfail) mechanism instead of a strict `-all` (fail). This tells receivers, 'If the email comes from an IP not listed here, you should probably be suspicious, but hey, it's your call.' It's permissive, avoids issues with mail forwarding, and, crucially, is good enough for most gateways to issue a `spf=pass`.

DomainKeys Identified Mail (RFC 6376) is even easier. Generating a public/private key pair and publishing the public key in another DNS TXT record is a one-time, 10-minute task. They configure their mail transfer agent (MTA), like a simple Postfix instance on their VPS, to sign all outgoing mail. This proves that the email originated from a server authorized by the domain owner. It does *not* prove the domain owner is trustworthy.

DMARC (RFC 7489) ties it all together. An attacker will publish a DMARC record with `p=none`. This is the key. This policy translates to: 'Hey receiving servers, I'm doing DMARC! Please check for SPF and DKIM alignment, but if it fails, do absolutely nothing. Just let it through.' A `p=none` policy allows them to get that coveted `dmarc=pass` without any risk of their emails being rejected or quarantined if something goes wrong. It's security theater, and it works.

Authentication-Results: mx.example.com; dkim=pass header.i=@corp-login.net; spf=pass (example.com: domain of support@corp-login.net designates 203.0.113.45 as permitted sender) smtp.mailfrom=support@corp-login.net; dmarc=pass (p=NONE sp=NONE) header.from=corp-login.net — A typical header from a well-crafted phishing email

Checking the Camouflage: Using Blue Team Tools against Themselves

Attackers don't fly blind. Before launching a campaign, they conduct reconnaissance on their own infrastructure using the exact same tools a SOC analyst would. They use public services like MXToolbox to verify their DNS records are set up correctly. They check their domain and IP against blacklists using Talos Intelligence, Barracuda's reputation tools, or VirusTotal's domain reports.

The goal is to scrub the infrastructure clean before it's ever seen by a real target. Is the SPF record valid? Does the DKIM signature verify? Is the sending IP on any blocklists? Is the website's threat score zero? They will methodically fix every issue until the domain passes with flying colors. A 'clean' report from these tools is the green light to proceed with the attack. They are, in effect, running a quality assurance check on their own phishing kit.

Hunting the Hunters: Finding Pre-Attack Infrastructure

If attackers are preparing for weeks, it gives us a window to find them. The entire pre-flight process leaves a trail of breadcrumbs in public and semi-public data sources. The true defensive mindset isn't just about analyzing emails post-delivery; it's about hunting for the attacker's staging grounds before the first shot is fired.

Certificate Transparency (CT) logs are a goldmine. These public logs record every TLS certificate issued by trusted Certificate Authorities. You can monitor these logs in near real-time for certificates issued for domains that are designed to look like yours: `yourbrand-login.com`, `support-yourbrand.io`, etc. Finding a newly issued certificate for a typosquatted domain is a high-fidelity signal of an impending campaign.

Passive DNS (pDNS) databases are another powerful tool. By analyzing historical DNS resolutions, you can identify newly registered domains that resolve to IPs in suspicious or non-traditional hosting environments. You can pivot on ASNs, registrars, and CIDR blocks known to be favored by threat actors to find other domains that are being aged for future use. This is proactive threat hunting, and it's how you get ahead of the phishing curve.

The takeaway

A `pass` on SPF, DKIM, and DMARC is not a certificate of good character. It is, at best, a proof of domain ownership. A patient attacker can and will achieve these passing grades as a prerequisite for their campaign. The presence of these passing headers should not be a signal to trust an email, but rather the starting point for deeper analysis.

Instead of asking 'Did it pass?', the right question is 'Should this have passed?'. Context is king. An email from a 90-day-old domain you've never heard of, with a `p=none` DMARC policy, sent from a non-corporate IP block, should raise more alarms than a DMARC failure on a forwarded calendar invite from a known partner. Correlating signals-—domain age, registration data, DMARC policy strictness, and IP reputation—is how you spot the wolf in sheep's clothing. It's the only way to separate a valid configuration from a valid threat.