Update 2/26/2024: Research published this week from Guardio Labs sheds additional detail on the pervasiveness of the subdomain hijacking attacks we wrote about in this article. The research also performs a more detailed technical analysis along with a tool for checking a database of known compromised domains: https://guard.io/subdomailing.

An unfortunate reality of email sender reputation is the ability for it to be weaponized. Of course, as senders you can do a whole bunch of things to protect yourself from malicious activity, and the effect is not only protection, but a positive sender reputation. Mailbox providers (MBPs) use reputation information to protect their own systems and end users. If a sender has a negative reputation, they’ll handle their mail differently than a sender with a positive one.

You probably know all this.

Something you might not know, though, is there is a new attack in town, and it involves malicious actors stealing your existing domain reputation to get their own spammy content past filters which then wreaks havoc on your email program. With the holiday season approaching, this is something you do not want to sweep under the rug.

Here’s what we know about what is happening and what advice we’re sharing with our customers on how to protect your domains from catastrophe.

The usual suspect: reputation theft

Since modern anti-spam filters focus so heavily on sender reputation, this is what attackers need to steal in order to get their messages past the filters. The tactics aren’t unusual, frankly. It’s reputation theft, plain and simple, but that means you’ll need to understand the basics before we can get into this specific threat.

IP reputation

The original form of reputation theft is IP reputation theft. This happens whenever a server is compromised, which could be your mail transfer agent (MTA), your email service provider (ESP) accounts, and so on.

This is most commonly seen via credential theft. Here’s how that might work: Microsoft Exchange is compromised because one of the users gets fooled with a phishing scam and their user credentials are stolen. This gives an attacker access to send mail through that server. The same can happen with SMTP credentials that leak via an attack such as the Laravel SMTP crack.

Yet…this isn’t exactly what we saw recently. Instead, these crooks went not for the server and its IP address, but for the domain. This is more complex and challenging to solve but is an equal threat to your email program.

Domain reputation

First things first. A message needs some kind of authentication mechanism to pass before the message is formally associated to a specific domain:  This can be via either a DKIM signature or SPF authentication. So, when a message carries a form of authentication, a mailbox provider like Google can know with some certainty this message did indeed come from the domain indicated.

One of the interesting example of how attackers have sent mail authenticated as another entity recently is via DKIM replay attacks. We have an in-depth look at DKIM replay attacks here. Needless to say, they can quickly tank an email reputation. The good thing about DKIM replays is the attacks focused mostly on Email Service Providers, and rarely impacted brands, marketers and traditional email senders, limiting the scope of overall email ecosystem impact to some degree.

Beyond DKIM replay, domain reputation can stolen by having messages pass SPF authentication via a given domain. An old-school way of leaching domain reputation via SPF authentication is when a brand or domain makes an error in their SPF record. For instance, instead of including one IP or a small range, some SPF records accidentally include a much wider range than intended. After you made the whoopsie and authenticated a big range, spammers will hunt for ways to get access to an IP address. With the prevalence of cloud services somethings it is as easy as signing up for an account at Amazon Web Services and moving an EC2 instance across different regions until it lands on an IP listed in the SPF record.

If their new IP address is listed in the SPF record of a known brand, they can send authenticate messages from that brand, essentially assuming the brand’s reputation.

One way this abuse is mitigated is that mailbox providers will notice if you have an unusually large range (maybe larger than a /16) and won’t associate messages authenticated from that range with a domain’s reputation. But still, this is Spooky.

A new suspect is identified

At some point, spammers realized subdomains share a reputation with their parent domain. While there are technical semantics about where the message comes from, the fact is many domain reputation systems share and commingle domain reputation scores with subdomains.

We first saw this weaponized by attackers when they were exploiting domains sold by registrars that were not considered as official top-level domains. You can learn more about it right here.

Now spammers are looking at big, high-reputation domains and running lookups combing through their DNS records. From there they can find something called a “dangling domain” or a “hanging CNAME”.  This is where a DNS record is pointing to another location that does not exist.

Wait — Why would someone have a hanging CNAME?

Don’t judge. There are any number of reasons and they can be super easy to have just by accident.

Here’s an example: Let’s say Big Brand A (http://brand.com) hires a web designer for a special marketing project, and the designer asks the brand to designate a subdomain (holidaycontest.brand.com) and point it to her own web hosting platform (brand.webdesigner.com). This CNAME record essentially redirects all DNS queries from the brand to the web designer, giving her control to execute the custom contest website.

But oh no. Oh noooo. The following year the web designer goes out of business and her domain registration expires. The domain is unregistered. But the DNS record pointing from brand.com to this designer still DOES exist. And there’s the rub.

Hanging CNAMEs can be weaponized

The DNS CNAME record still redirects queries, even if the destination is an unregistered domain. Bad actors are searching for these hanging records so they can control the destination domain. When they find one, they’ll buy and register the domain (webdesigner.com).

Once they own the domain, spammers can publish an SPF record. Since DNS queries for Big Brand’s subdomain still redirect to the malicious actor, it’s as if the actor has full control over the SPF record for the brand’s subdomain.

The malicious actor can officially send SPF authenticated mail using Big Brand A’s subdomain, which gets messages past spam filters and into the inboxes of unsuspecting users.

Here’s an example (don’t worry, we’ve already contacted the affected brand’s security team and the CNAME has been removed).

Consequences can be dire

What does this mean in simple terms?

There are huge volumes of spam messages that mailbox providers like Google are associating with legitimate brand domains from a reputation perspective.

Your sending reputation as a brand at a mailbox provider like Google could be abysmal if you’re the subject of one of these attacks. This might put your email deliverability rates to Gmail inboxes severely at risk. That means higher bounce rates and more emails landing in the spam folder.

Imagine a holiday season in which you cannot reach any potential customers using a Gmail address? No don’t, it’s too scary and we can’t be held liable for any emotional damage the vision may cause.

But seriously…this level of reputation damage could be catastrophic to brands who rely on the ability to reach their consumers via email. So, basically everyone.

Stay vigilant

We won’t sugar-coat it: there aren’t many things you can do to prevent this kind of attack.

The unfortunate reality is, there could be any number of subdomains for your business that no one knows about. Think back to our example. The subdomain was created and pointed in good faith for a good reason. If the original contractor goes out of business, they likely won’t inform every client they’ve ever worked with that they’re closing up shop.

What CAN you do?

Awareness is your best defense

There are some reputation smoke signals you can find in your Google Postmaster Tools. The reputation of a domain would decrease significantly, and a large plethora of random IP addresses may appear on the IP reputation page.  If you see both of these things happening, you need to consider this as a potential source of the problem.

You may notice variance within email marketing metrics including bounce rates, open rates, unsubscribes and spam complaints.

You may find SMTP error codes being returned by Google such as: 

• 451 4.7.24 The SPF record of the sending domain has one or more suspicious entries. To protect our users from spam, email sent from your IP address has been temporarily rate limited. For more information, go to Email sender guidelines.
• 421 4.7.0 [IP ADDRESS] Our system has detected that this message is suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/188131 for more information. {SMTP ID} – gsmtp 
• 550 5.7.1 [IP] Our system has detected that this message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/188131 for more information. {SMTP ID} – gsmtp 

There are software solutions for understanding DNS attack surface footprints such as Security Trails and DomainTools but based on the success rate of the attackers, tools like these may not be deployed as widely as organizations need.   

One interesting aspect of these attacks is that DMARC reports do not assist in the identification of such activity. DMARC reports are only sent regarding messages where the From Address in the message headers has a DMARC policy. The attackers appear to only be using the compromised subdomains in the return path address of malicious messages.  They do this because this is the address used in the SPF the analysis process, and therefore the domain that can be reputationally attached to a message. In the samples we’ve seen, the attackers are not using the brand subdomain in the message headers as the end-user visible From address which DMARC protects. 

Spammers are burning these email domains quickly. They’ll typically only use a domain for a few days before moving to the next. After all, you can’t spend anymore money when the account is empty, right? Once a brand’s reputation is tanked, they need to find a better reputation to use to get mail delivered.

Stay calm

Let’s say you find yourself a victim of this scheme. You can spend a few minutes panicking, but then you need to kick into high gear. To repair your reputation, we’ve been encouraging our customers to rely on best practices.

• Stop the stream and re-warm. Immediately remove the CNAME records from DNS and cutoff the attackers control of your subdomain. Even if you haven’t been blocklisted, you may want to stop sending. Why? Because you may need to re-establish confidence in your sending domains, so treat this as though you’re starting over, going through the warm up process again.
• Determine if you need to disclose the breach. Depending on the severity, you might be legally required to publicly report the hijacking. Regardless of legality, it’s a good practice to acknowledge the event, urge anyone who might have been fooled to change their passwords, and commit to and communicate future plans to prevent this from happening again. 
• Purposefully segment your list. Find your most reliably engaged recipients and send ONLY to them during your re-warming period. Add in more engaged recipients as you scale. This will signal to MBPs that you understand the concept of wanted mail. 

Parting advice

You need to diligently monitor your performance data. It’s non-negotiable. This is really the only way you can protect yourself from these attacks, because unless you have an exhaustive list of all your subdomains and where they point to (and whether those endpoints are still valid), sudden nosedives will be your only clue this happened. It isn’t exactly a comforting message, true. But knowledge is power.

Good luck. And if you need some help, reach out to us. We love to talk email.