A significant number of well-known organizations have been attacked as part of what’s being called the SubdoMailing (Subdo) campaign that has been going on since at least 2022, research by Guardio Labs has revealed.
The scale of execution of this attack is staggering, and the impact is hugely damaging, but the goal is simple – to send mail to victims from trusted brand names in order to deceive them into taking action. This complex attack takes advantage of key human and technical weaknesses in the Domain Name System (DNS) that is the backbone of the internet.
So far, the campaign has sent at least 5 million emails each day from more than 8,000 compromised domains and 13,000 subdomains. But how does it work, what’s the damage caused by the attack, and how can you protect yourself against it now and in the future?
How the SubdoMailing attack works
In this campaign, malicious mail is sent, usually authenticated, from domains and subdomains that have been compromised through three different types of domain takeover. Here’s how it works in practice, using three different scenarios from my fictitious work history.
Takeover of a branded domain
Let’s say a long time ago, I decided to start a cat food business called “Billy’s Fresh Cat Food”. I registered the domain billysfreshcatfood.com to use for my ambitious venture. I had lots of budget, so decided to spend some money with a well-known and trusted advertising network “Del’s Ads”. For this example they use the domain delsads.com. For the campaign, the ad network set up the CNAME “billysfreshcatfood.delsads.com” to “billysfreshcatfood.com”.
The campaign did ok, but alas, the market was not ready for my amazing cat food. So the business went under, and the domain registration expired. But the ad network didn’t know it expired and didn’t remove my domain from their DNS configuration, creating a dangling DNS record.
Roll on ten years. Using passive DNS, a bad actor found that the subdomain was still in DNS pointing to “billysfreshcatfood.com”. They’ve then reregistered my expired domain “billysfreshcatfood.com”, configured it for sending mail, and updated the DNS with updated authentication records. This is now a poisoned domain.
The subdomain is still acting as an alias for the newly reregistered domain. This means the subdomain inherits the SPF policy of the domain that’s now back in DNS. So now, the bad actor could send emails as the trusted ads network “Dels Ads” using the CNAME “billysfreshcatfood.delsads.com”.
Takeover of a domain used in SPF
After my cat food business failed to take off, I started “Billy’s Trees”—billystrees.com—selling overpriced cat scratching posts to millennials. This time, it was a great success.
I decided to expand the business and took my marketing seriously, using an email marketing platform called “Leads R Us”. When setting it up, they asked me to add “leadsrus.com” to my SPF policy so that the marketing platform was authenticated to send emails from my domain.
Sadly, “Leads R Us” wasn’t as successful as my business and they went bust. I changed to a different provider, but forgot to take “leadsrus.com” out of my SPF policy. That created a dangling SPF record.
“leadsrus.com” was abandoned, but a bad actor identified it and purchased the domain. This is now a poisoned domain. And since “leadsrus.com” is still in my SPF policy, the bad actor could send mail as “billystrees.com”.
Registration of a domain used in user documentation
Honestly, after “Billy’s Trees”, I was a bit tired and fed up with all the cyber attacks. I decided to stick to my strengths, and I started up a consulting business to help small businesses implement email authentication.
To help, I created an online wiki that included a step-by-step guide to set up DMARC. In the guide, when talking about how to add a domain to the SPF policy, I used an example unregistered domain “yourauthorizeddomain.com”.
As I was working with customers who had little technical knowledge, some people did add the example unregistered domain to their SPF policy rather than the domain they intended to authorize.
Sometime later, “yourauthorizeddomain.com” was identified and then registered by a bad actor, turning it into a poisoned domain. Unfortunately, this meant that the bad actor could send emails as the customers who included “yourauthorizeddomain.com” in their SPF policy.
The scale of the infrastructure used
The actor behind this attack has built a significant amount of infrastructure to execute this attack and continues to acquire assets to support it.
So far, our team has identified over 100 poisoned domains that have been created or taken over to be added or used in SPF policies. Some are takeovers of abandoned domains—I bet the now closed Harrisburg Jet Center never expected to be involved in a cybersecurity attack—but many are deliberate impersonation attempts of trusted consumer and technology brands including Amazon, Lacoste, and Citrix. Behind those domains are tens if not hundreds of thousands of IP addresses being used to support the mail servers, a normal technique used in this type of snowshoe attack.
What’s a poisoned domain and what is DNS poisoning?
A poisoned domain is a domain created by an attacker, generally using a domain generation algorithm (DGA), that has the actual payload of the IPs being used in the attack. These domains are then used in the hijacked domains as part of the SPF tree.
What’s the damage caused?
The research by Guardio Labs surmises that the goal of the bad actor running this campaign is monetization through ad-clicks performed by the user. This type of fraud may be the primary objective in this case, but the scale of this type of business email compromise lends itself to other damaging activity, such as malware downloads. It won’t be surprising to find it’s been used for other nefarious exact impersonation attacks.
And domains and subdomain takeovers aren’t just useful for sending emails. Once a name is in the control of someone else, they can use it for web services, and then easily mislead individual and corporate victims into providing personal and payment information.
When combined with social engineering techniques, domain and subdomain takeovers can be very damaging.
It is also important to remember the indirect damage caused to the reputation of organizations that have had their domains, subdomains, and brands used in this attack. This materially reduces trust which is essential in transactional and marketing mail.
Why is this type of attack possible?
In my introduction, I mentioned that this attack takes advantage of human error and technical weaknesses in the Domain Name System (DNS). Some are technically avoidable and some require supporting people to understand processes and consequences. These weaknesses include those mentioned below.
Authentication is inherited
Depending on the configuration of the domain that’s been taken over or the domain that has the taken-over domain in its SPF policy, mail sent from the subdomain is often sent authenticated not only using SPF but also using DMARC and DKIM. This is because the CNAME is a pointer to the DNS zone of the destination.
Domain name registration expiration
In the excellent “Managing Mission-Critical Domains and DNS” Mark E. Jeftovic talks about “foibles that may seem trivial…then…I’d get an email from a customer, friend or acquaintance about the exact section.”
These foibles lead to unintentional human error. A Whois record isn’t correctly updated, a domain expiration is missed or forgotten about, someone decides that a domain is no longer required and should be abandoned. 70 percent of all web domains fail to be renewed one year after purchase so there is plenty of low-hanging fruit for bad actors to go after.
Forgotten DNS records lead to dangling DNS issues
In our Hardenize blog, we talk about dangling DNS in detail. Dangling DNS issues happen because DNS changes that have been made are easy to forget about. DNS is configured separately from the networking layer, so multiple steps are required to point a domain or subdomain to a web or email service. Reversing changes doubles the work, and often services aren’t removed from DNS when they’re redundant because someone forgets or there is a programmatic failure.
In a lot of cases, this is a hygiene issue. But as demonstrated by the SubDo attack, a forgotten DNS record that becomes dangling for a variety of different reasons can lead to a domain or subdomain takeover. In some cases, it can also lead to a nameserver takeover, giving a bad actor complete control of your DNS.
People are, well, people
The user documentation example highlights that well-intentioned people make mistakes. When writing user documentation, it’s almost impossible to imagine that fake domains included to help users understand a scenario would be abused in such a way.
How the exploit can be prevented
Don’t let your domain names expire
Some say don’t let any meaningful domain names expire. But really, you shouldn’t let any previously registered domain names expire. The cost of registration and maintenance is generally very low while the cost of cleaning up all references is high.
Keep your DNS clean
Remove resource records from your DNS that are no longer in use, and remove third-party dependencies from your DNS when they become redundant. Make sure that this work is scheduled regularly by your infrastructure team.
Use a trusted email protection provider
It makes sense to use a vendor for your DMARC, DKIM, SPF and MTA-STS requirements. Your email is critical infrastructure to your organization, so you should use a trusted vendor with the capability to proactively tell you when something doesn’t look quite right. It is important, for example, to use a vendor that will tell you when a domain that is part of your SPF policy is void.
Check for dangling DNS records
Build an inventory of your hostnames, and monitor them continuously for dangling resource records and third-party services. When identified, remove them immediately from your DNS. This is a workflow that should be added to your Security Operations Centre (SOC), giving analysts enough information to identify, triage and allocate remediation work correctly.
Monitor what sources are sending from your domain
If your domain or subdomain is taken over for sending, then it is important that you know if mail is being sent from it as quickly as possible. So when picking your trusted email protection vendor, make sure that they can tell you about mail being sent from all sources.
Monitor the domains of the infrastructure supply chain you depend on
The Subdo campaign re-registered domains that were abandoned by vendors that organizations relied on for key services such as payment gateways. You should proactively monitor at least the primary domains of your supply chain, including domains that are included in your SPF policy, and take action if the web or email services become available.
How the Red Sift Pulse Platform helps to continuously and proactively prevent these attacks
Continuous monitoring of your attack surface and dangling DNS checks using Red Sift ASM
Red Sift ASM continuously discovers and monitors assets at risk of this type of attack.
When a domain is discovered, it also discovers all subdomains that can be derived, checks for email and web services on each domain and subdomain, and carries out a full inspection of its DNS, email, and web configuration. This includes the key checks needed to prevent similar threats to SubdoMailing—domain name expiration monitoring so that you don’t lose control of your domains and finding dangling records and services so that you can clean your DNS. Asset discovery and monitoring is often in real-time, giving your team important knowledge when it’s needed—not in days, weeks, or months.
Continuous monitoring of sent email using Red Sift OnDMARC
Red Sift OnDMARC provides complete visibility of all outbound mail sent from your organization including all service providers. Using this, you can quickly identify sources sending email using your domain that shouldn’t be, highlighting any domain or subdomain takeovers quickly.
Red Sift OnDMARC also gives complete visibility of all raw and nested includes in your SPF policy.
Dynamic Services using Red Sift OnDMARC
SPF, DKIM, DMARC and MTA-STS implementations often result in errors as they’re difficult to manage, especially in complex environments. Dynamic Services simplifies the management of your email authentication records in one place. Replacing static DNS records with Dynamic Services smart records removes the need to make frequent changes with your DNS provider when changes are necessary.
Dynamic Services also adds robustness to email setups by using caching and error handling, and, in the event of a problem, self-healing, using the last known correct configuration as a fallback. If a domain used in your SPF policy becomes void, then Dynamic Services will detect that and notify you so that it can be resolved or removed, but will also self-heal so that mail authentication is unaffected.
How Red Sift can help immediately
SPF Checker
You can use Red Sift’s SPF Checker to check specific domains or subdomains to see if you or your organization is impacted by SubdoMailing. In seconds, it will tell you if a poisoned domain is found inside your SPF configuration.
Does your organization have a large number of domains and subdomains?
Get in touch and our team will arrange a session with you. We’ll build out your inventory automatically using Red Sift ASM, then check if poisoned domains are contained within the SPF policies of each domain and subdomain we discovered.
Are you an existing Red Sift customer?
Existing Red Sift customers can follow the latest updates on our work researching this attack by logging into the exclusive Sift Space ASM Community group.
