Burn Notice: A Red Teamer's Playbook for Vetting Phishing Infrastructure

The dashboard glowed red. It wasn't supposed to be red. The engagement hadn't even started, the initial access payload was still being polished, and yet, the primary C2 domain was already flagged. Somewhere, an automated security product had seen the new IP address, connected it to the newly-registered domain, and decided it was guilty until proven innocent, landing it on a minor but influential blacklist.

This is the new reality for offensive operations. The window of opportunity to establish a clean infrastructure baseline is shrinking. Automated reputation systems, Real-time Blackhole Lists (RBLs), and the general paranoia of mail exchange servers mean that your phishing infrastructure is under scrutiny from the moment it comes online. A single misstep during setup can burn your assets before they're ever used.

This isn't a guide for spammers. This is a playbook for professional red teamers who need to emulate sophisticated threats, and that requires navigating the same treacherous waters as adversaries. Success hinges on a meticulous, pre-flight vetting process. Let's walk through it.

Due Diligence Isn't Just for Blue Teams

Too many operators think infrastructure acquisition begins with a domain registrar and ends with a credit card. That's a mistake. The first step is reconnaissance. You are acquiring digital real estate, and you need to run a title search to see who lived there before you and what kind of trouble they got into.

Domain History & The Aftermarket

Before you register `acme-logins.com`, you must check its history. Has it been registered before? Was it used in a previous phishing campaign? Was it a parked domain that served up malware? Tools that provide historical WHOIS and passive DNS data are invaluable here. A domain that has existed for a year with no negative history is far more credible than one registered five minutes ago. A brand-new domain is a red flag for many filters.

Consider expired or auctioned domains. Acquiring a domain with a pre-existing, positive reputation is the holy grail. An old blog about model trains is unlikely to be on any blacklists. If you can acquire it and repurpose it, you start with a significant advantage. The risk, of course, is that its previous life might have hidden reputational baggage you failed to uncover.

IP Address Necromancy

The same due diligence applies to your IP space. Whether you're leasing a VPS from a budget provider or spinning up a VM in a major cloud, that IP address has a history. Before you even point your domain to it, query the IP against major RBLs like Spamhaus, SORBS, and Barracuda. If it's already listed, throw it back. Don't waste your time. The operational cost of starting with a tainted IP is immediate and often insurmountable.

There's No Such Thing as a 'Clean' IP

Let's be perfectly clear: when you get an IP address from a major cloud provider, you are not getting a new, pristine resource. You are getting a recycled number that someone else was using minutes or hours before. Cloud providers have massive IP blocks, and those addresses are in constant flux as users spin VMs up and down.

The operator before you could have been a legitimate business, a malware researcher, or an actual spammer. The RBLs don't know or care. They see malicious activity coming from `44.202.55.88`, and they list `44.202.55.88`. They don't track who was renting that address at the time. When you get assigned that IP, you inherit its reputation, for better or worse. Usually worse.

554 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using zen.spamhaus.org; See https://www.spamhaus.org/query/why/SBL... for details

If you see a bounce message like that in your mail logs, it's already too late. Spamhaus, a tier-1 RBL used by a huge percentage of mail servers, has your IP listed. Your emails aren't going to the spam folder; they're being rejected at the SMTP connection level. Your phishing campaign is over before it begins. This is why immediate, post-acquisition checks are non-negotiable. Don't assume. Verify.

Many of these cloud IP ranges are also included on policy-based block lists (PBLs), which identify dynamic or non-mail-server IP ranges. While not an indicator of malicious activity, sending from a PBL-listed IP can still hurt your deliverability. Your 'clean' IP might be clean of active abuse, but still considered an illegitimate source of email by default.

Automate or Die: Building Your Reputation Canary

Checking your assets for RBL listings once, at the beginning of an engagement, is insufficient. Reputation is volatile. You can be clean at 9 AM and blacklisted by noon. Manual, ad-hoc checks don't scale and are prone to human error. You need an automated system—a canary—that constantly monitors the health of your infrastructure.

Scripting RBL Queries

Most RBLs operate via DNS. To check if the IP `1.2.3.4` is listed on `zen.spamhaus.org`, you perform a DNS `A` record lookup on the reversed IP address prepended to the RBL's zone: `4.3.2.1.zen.spamhaus.org`. If a record is returned (typically `127.0.0.X`, where X indicates the specific list), the IP is listed. If you get an `NXDOMAIN` response, it's clean.

This process is trivial to script. A simple Bash or Python script, run via a cron job every few hours, can iterate through your list of C2 IPs and domains, query a dozen or so key RBLs, and alert you on a positive hit. This is your early warning system. It tells you a fire has started before the whole forest burns down.

Beyond Blacklists: End-to-End Deliverability

An RBL check tells you if you have a known-bad reputation. It doesn't tell you if you have a good one. The ultimate test is actually delivering an email. Your monitoring should include sending a benign test email from your phishing infrastructure to a set of canary mailboxes you control at major providers like Microsoft 365, Google Workspace, and a generic cPanel host.

Then, your automation needs to log into those mailboxes (via APIs like Microsoft Graph or IMAP) and check: Did the email arrive? Was it in the inbox or the junk folder? Was it dropped entirely? This provides ground truth on how the world's most common mail filters are treating your domain and IP, a far richer signal than a simple blacklist query.

The Triage: Burn, Remediate, or Ride It Out?

The alert fires. Your primary callback domain is now listed on a mid-tier RBL that a few of your targets are known to use. Panic is a choice. A good operator has a decision framework for this exact moment.

First, understand the listing. Not all blacklists are created equal. A listing on the Spamhaus SBL or a major security vendor's feed is a critical event. Your traffic is being blocked, period. A listing on an obscure, over-zealous, or informational list might be pure noise. Investigate the RBL itself. Is it reputable? How does it make listing decisions? What's the impact?

The Default Action: Abandonment

For a red team engagement with a defined timeline, the correct response is almost always to abandon the asset. Your time is the most valuable resource you have. Spending hours or days trying to get an IP delisted is an operational dead end. The delisting process is designed for system administrators, not covert operators. It's often slow, requires public acknowledgement, and may not even succeed.

Have your next set of assets warmed up and ready to go. Your automation should have already vetted them. The goal is to rotate to a clean domain and IP with minimal downtime. Treat your infrastructure as cattle, not pets. When one gets sick, you don't call the vet; you replace it.

The Last Resort: Remediation

Sometimes, abandonment isn't an option. The domain might be hard-coded into payloads that have already been deployed to critical targets. Or perhaps it's a high-value, aged domain you can't easily replace. In these rare cases, remediation might be your only path.

Follow the RBL's delisting procedure to the letter. This is no time for creativity. If the IP was listed, remove the A record for your domain, ensure no malicious activity can possibly originate from it, and then submit the removal request. Be prepared to wait. This Hail Mary play will cost you significant time and may not work, but if the alternative is a failed objective, it's a chance you might have to take.

The takeaway

A phishing domain reputation check isn't a single task you cross off a list. It's a continuous state of vigilance. Your infrastructure's reputation is a dynamic asset that must be managed from acquisition through execution to teardown. By front-loading the due diligence, automating your monitoring, and having a clear decision framework for when things go wrong, you move from being a victim of automated defenses to a master of them.

Proactive monitoring is the difference between a successful engagement and a costly, embarrassing failure. While the scripting techniques described here are a powerful start, comprehensive platforms like MailSleuth.AI can provide deeper insight into how mail systems are truly interpreting your messages, analyzing headers and delivery paths to give you a complete reputational picture beyond a simple RBL hit.