HADES Attack: Understanding and Evaluating Manipulation Risks of Email Blocklists

HADES Attack: Understanding and Evaluating Manipulation Risks of Email Blocklists

Speakers: Ruixuan Li (Siha University)

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=BPJixJs74MY

Overview

In the realm of cybersecurity, email remains a critical communication channel, and its integrity is constantly under threat from spam and malicious actors. To combat this, DNS-based Blocklists (DNSBLs) serve as a cornerstone defense mechanism, aggregating intelligence on abusive email servers and domains. However, the talk "HADES Attack: Understanding and Evaluating Manipulation Risks of Email Blocklists" by Ruixuan Li from Siha University unveils a significant vulnerability in this system. The presentation introduces the Hades attack, a novel method by which attackers can maliciously inject legitimate email servers and domains into these blocklists, severely disrupting email deliverability and potentially leading to the deletion of victim domains by registries.

The Hades attack highlights a critical flaw: the reliance of DNSBLs on capture servers (such as spam traps) for intelligence gathering. By identifying and manipulating these capture servers, attackers can trick DNSBL providers into misclassifying benign entities as malicious. This research is profoundly important because it exposes how a foundational defense mechanism against spam can be weaponized to silence legitimate communication. The implications extend from individual email users facing delivery failures to large organizations and even domain registries, underscoring the need for a re-evaluation of current DNSBL design and operational practices.

Background

▶ Watch: Introduction to HADES attack and its impact (0:00)

The fight against spam and email-borne threats heavily relies on DNS-based Blocklists (DNSBLs), also known as Real-time Blackhole Lists (RBLs). These lists compile IP addresses and domain names of email servers identified as sources of spam, malware, or other abusive activities. Email service providers and mail server software widely adopt DNSBLs to filter incoming mail, rejecting or flagging emails originating from blocklisted entities. Beyond email filtering, some domain registries even use DNSBLs as a criterion for deleting malicious domains, adding a severe consequence to being listed.

DNSBL providers typically build their lists by actively detecting spammers and passively collecting data. A key component of this intelligence gathering involves capture servers. These specialized servers are designed to attract and identify spammers. The most prominent type of capture server is a spam trap, which is an email address or domain that should never receive legitimate email. Spam traps are not disclosed publicly; their sole purpose is to capture emails sent by automated spam bots or spammers who harvest email addresses indiscriminately. When a spam trap receives an email, it's a strong indicator that the sender is engaged in spamming activities, leading to a high-confidence blocklisting. Other capture mechanisms include email relay servers that track suspicious forwarding activities and data sharing sources from trusted partners. The effectiveness of DNSBLs, therefore, heavily relies on the integrity and secrecy of these capture servers. If attackers can identify and exploit these capture mechanisms, they gain the ability to manipulate the entire DNSBL ecosystem, turning a defense mechanism into an attack vector. This inherent reliance on covert capture servers creates the very vulnerability that the Hades attack exploits.

Key Findings

▶ Watch: HADES attack vulnerability: manipulating capture servers (2:30)

The research behind the Hades attack uncovered several critical findings that underscore the pervasive risks associated with DNSBL manipulation:

1. Prevalence of DNSBL Adoption: Despite concerns about potential mislistings, DNSBLs are widely adopted. The study found that 90% of domains deploying DNSBLs use Spamhaus, one of the largest and most influential blocklist providers. Furthermore, 53% of the top 100 domains globally utilize DNSBLs for email filtering. Seven popular email providers deploy IP-based blocklists, and three, including Outlook and ESET, deploy domain-based blocklists, indicating a significant attack surface.
2. Discoverability of Spam Traps: Contrary to the assumption that spam traps are secret and difficult to find, the researchers developed a methodology to effectively identify them. By analyzing exposed features (e.g., accepting all emails, not sending emails, specific DNS record configurations), they were able to narrow down 30 million email domains from four sources to potential spam trap candidates. Through a careful verification process involving active sending to 21 selected domains, they successfully identified the spam traps of 14 different DNSBL providers. Notably, they discovered approximately 14,000 spam trap domains belonging to Spamhaus, demonstrating a high degree of success in bypassing the intended secrecy of these systems.
3. Effectiveness of Blocklist Injection: The Hades attack proved highly effective in injecting legitimate IPs and domains into DNSBLs. IPs were typically blocklisted within two hours, with some providers like Spamhaus blocklisting an IP in as little as three minutes when emails were sent at a rate of one per second to identified spam traps. Domains took slightly longer, usually over six hours, but were equally susceptible. While most blocklistings are automatically removed after seven days, five DNSBL providers identified in the study do not support early removal, prolonging the impact of an attack.
4. Attack Surface on Popular Services: The study inferred the attack surface by monitoring blocklist histories of outgoing mail servers for the top 1,000 Adobe domains over two months. They found that 70% of these outgoing servers, including those from major providers like Hotmail, Gmail, and Yahoo, had historically been blocklisted. This indicates that even major email providers are not immune to being targeted by Hades, and their automatic email servers (e.g., for subscriptions or password resets) present a feasible vector for disruption.
5. Risk of Domain Deletion: Perhaps the most severe finding is the potential for domain deletion. The researchers confirmed that four domain registries use DNSBLs to delete blocklisted domains. This means that a successful Hades attack could cause a victim's domain to disappear entirely from the internet, affecting domains under 151 different Top-Level Domains (TLDs). This consequence extends far beyond mere email deliverability issues, posing an existential threat to online presence.
6. Attack Variants: The research identified three primary variants of the Hades attack:

• Internal Attacks: An attacker with a legitimate account within the victim's email provider sends emails directly to identified capture servers.
• External Attacks: An attacker outside the victim's provider indirectly induces the victim to send emails. This often involves exploiting features like email subscription services or password reset mechanisms on websites, where submitting a capture server's email address triggers an automated email from the victim's server.
• Spoofing Attacks: When capture servers do not perform stringent sender identity checks (like SPF), attackers can use any controlled server to send emails to capture servers, spoofing the victim's domain as the sender.

These findings collectively paint a concerning picture of the fragility of the DNSBL ecosystem and the significant power an attacker can wield with minimal effort to disrupt critical online services.

Technical Deep Dive

▶ Watch: Real-world deployment and adoption of DNSBLs (5:00)

The Hades attack leverages a deep understanding of how DNS-based Blocklists (DNSBLs) operate and how spam traps are integrated into their intelligence gathering. The core technical premise is to identify these hidden capture servers and then orchestrate scenarios where legitimate email infrastructure is tricked into sending emails to them, thereby triggering a blocklist entry.

The construction of DNSBLs relies on various sources, primarily capture servers. These include:

• Spam traps: Email addresses or domains specifically set up to catch spam. They are typically dormant, never used for legitimate communication, and thus any email received indicates spam activity.
• Email relay servers: Monitoring points for suspicious email forwarding patterns.
• Data sharing sources: Information exchanged between trusted security partners.

The talk emphasizes that spam traps are particularly critical because they are designed to be secret and provide high-confidence indicators of maliciousness.

The Hades attack methodology can be broken down into two main phases: spam trap discovery and blocklist injection.

Spam Trap Discovery

This is the most technically intricate part of the attack, as DNSBL providers deliberately keep their spam trap locations secret. The researchers developed a three-step process:

1. Email Address Collection: The first step involved collecting a vast dataset of email addresses and domains. The team amassed approximately 30 million email domains from four diverse sources to maximize the likelihood of covering domains that might host spam traps. The focus was on domain names for initial analysis.
2. Candidate Selection via Exposed Features: The key insight here is that spam traps, acting as honeypots, exhibit specific, observable behaviors. They are designed to passively capture spammers without actively sending emails themselves. Therefore, spam trap domain candidates were identified by filtering for domains that:

• Accept all emails: Regardless of the local part (the part before the '@'), these domains accept incoming mail, a common characteristic of spam traps designed to catch any address harvested by spammers.
• Do not send emails: Spam traps are typically passive listeners and do not originate outgoing mail.
• Exhibit specific DNS record patterns: While not explicitly detailed, this likely involves looking for anomalies or specific configurations in MX, A, or other DNS records that might indicate a non-standard email setup.

This filtering process, relying only on DNS record queries and sending emails to non-existent addresses (to check the "accept all" feature without triggering an actual blocklist), allowed the researchers to filter out 99% of email addresses, significantly narrowing down the candidate pool.

1. Verification of Spam Trap Domains: To confirm actual spam traps while minimizing ethical risks, a careful active verification step was performed. The team selected only 21 domains from their candidates for active testing. They sent emails to these candidates from a controlled IP address. If the sending IP address subsequently appeared on a DNSBL, it provided strong evidence that the candidate domain was indeed a spam trap. This iterative process allowed them to refine their list until accurate spam traps were found. Through this method, the researchers successfully identified the spam traps of 14 different DNSBL providers, including a significant 14,000 spam trap domains belonging to Spamhaus.

Blocklist Injection Mechanisms

Once spam traps are identified, the Hades attack proceeds with injecting legitimate entities into blocklists. The attack manifests in three primary variants:

1. Internal Attacks: This is the most straightforward. An attacker with a legitimate account on a victim's email provider simply sends emails directly to the identified spam traps. Since the emails originate from the victim's infrastructure, the victim's IP address or domain gets blocklisted.
2. External Attacks: This variant is more sophisticated, as the attacker does not have direct access to the victim's email system. Instead, the attacker leverages common web functionalities that trigger automated emails. Examples include:

• Email Subscription Services: The attacker subscribes to a victim website's newsletter using a spam trap email address. The website's mail server then sends a confirmation or welcome email to the spam trap.
• Password Reset Functions: The attacker initiates a password reset for an account on a victim website, providing a spam trap email address for the reset link. The website's mail server sends the reset email to the spam trap.

In both cases, the victim's outgoing email server, which is legitimate, is tricked into sending mail to a spam trap, leading to its blocklisting.

1. Spoofing Attacks: This variant exploits a weakness in some capture servers' sender identity verification. If a spam trap or DNSBL provider does not rigorously check sender authenticity mechanisms like Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM), an attacker can use any controlled server to send emails to the spam trap. Crucially, they spoof the sender's domain to appear as the victim's domain. As the number of spoofed emails originating from the victim's domain (even if not from their actual server) increases, the DNSBL provider may eventually blocklist the victim's domain itself.

The impact of these injections was rapid. Sending emails at a rate of one per second, IPs were typically blocklisted within two hours, with Spamhaus showing an IP blocklist in just three minutes. Domain blocklistings occurred within six hours. The subsequent effect on email deliverability is immediate: incoming mail servers querying DNSBLs will reject or flag emails from the blocklisted victim.

The research also highlighted that Spamhaus did not strictly verify sender identities, making it particularly vulnerable to spoofing attacks targeting domains. Furthermore, the duration of blocklisting varies; while many DNSBLs automatically delist after seven days, five providers were identified that do not support early removal, prolonging the attack's impact.

This deep dive reveals the intricate steps involved in the Hades attack, from the covert identification of critical defensive infrastructure to the strategic manipulation of common email and web functionalities, ultimately undermining the reliability of a core internet service.

Demo / Proof of Concept

▶ Watch: Methodology for discovering hidden spam traps (6:40)

While the talk did not present a live, interactive demonstration in the traditional sense, the researchers thoroughly demonstrated the feasibility and effectiveness of the Hades attack through their rigorous evaluation methodology. Their "proof of concept" was the successful execution of each stage of the attack, providing concrete evidence of its viability and impact.

The core of their demonstration involved:

1. Spam Trap Discovery Validation: The researchers successfully identified thousands of spam traps belonging to various DNSBL providers, including 14,000 Spamhaus spam traps. This step alone served as a powerful proof of concept for their discovery methodology, showing that the supposed secret locations of these critical defensive tools are, in fact, discoverable.
2. Blocklist Injection Execution: The team actively demonstrated the ability to inject IP addresses and domains into DNSBLs. They describe sending emails at a rate of one per second to identified spam traps. This controlled experiment showed that:

• IP addresses were typically blocklisted within two hours.
• Crucially, Spamhaus blocklisted an IP address in just three minutes, highlighting the speed and sensitivity of some DNSBLs to perceived spam activity.
• Domains were successfully blocklisted, albeit taking slightly longer, usually more than six hours.

1. Vulnerability to Spoofing: The research explicitly noted that Spamhaus does not strictly verify sender identities, allowing attackers to inject spoofed domains. This was a critical demonstration of a specific vulnerability that enables a more potent form of the Hades attack.
2. Impact on Popular Services: By analyzing historical blocklist data, the researchers effectively demonstrated that even major email providers like Hotmail, Gmail, and Yahoo have had their outgoing servers blocklisted in the past. This provides strong inferential proof that these popular services are indeed susceptible to the Hades attack, especially through their automated email functions (e.g., password resets, subscriptions).
3. Domain Deletion Risk: The most severe consequence was demonstrated by identifying four registries that use DNSBLs for domain deletion, affecting domains across 151 TLDs. While the researchers did not actively delete a domain (due to ethical considerations), their findings confirm the mechanism by which a Hades attack could lead to such a catastrophic outcome, serving as a conceptual but impactful proof of concept for the ultimate risk.

In essence, the entire research process, from methodology to results, served as a comprehensive proof of concept for the Hades attack. It moved beyond theoretical speculation to empirically show that DNSBLs can be manipulated, legitimate entities can be blocklisted, and severe consequences like domain deletion are a tangible threat. The controlled and ethical approach to testing, particularly the careful selection of only 21 domains for active detection, ensured that the demonstration of impact was robust without causing undue harm.

Defensive Implications

▶ Watch: Attack surface and vulnerability of popular email providers (9:30)

The Hades attack reveals fundamental weaknesses in the current DNSBL ecosystem, necessitating a multi-faceted defensive strategy for email providers, website administrators, and DNSBL operators alike. The speaker briefly touched upon several key mitigation strategies during the Q&A, and a deeper analysis reveals further implications:

1. DNSBL Provider Enhancements:

• Diversify Capture Intelligence: DNSBL providers should move beyond relying solely on spam traps. As the speaker suggested, incorporating many types of capture mechanisms and cross-referencing intelligence from multiple sources can make it harder for attackers to manipulate the system by targeting a single type of sensor.
• Stricter Sender Identity Verification: For domain blocklists, providers must implement rigorous checks for sender identity. This includes validating SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) records. The finding that Spamhaus did not strictly verify sender identities for domain blocklisting is a critical vulnerability that needs immediate attention.
• Improved Anomaly Detection: DNSBL providers should develop more sophisticated algorithms to detect unusual patterns in blocklist triggers. For instance, if a highly reputable domain or IP, which typically sends only legitimate emails, suddenly triggers multiple spam traps within a short period, this should raise a red flag for potential manipulation rather than immediate blocklisting.
• Enhanced Delisting Processes: While automatic delisting after seven days is common, the fact that five providers do not support early removal is problematic. Streamlined and transparent processes for legitimate entities to request immediate delisting upon proving their innocence are crucial to minimize downtime and damage.
• Protecting Exposed Features: The speaker's suggestion of "not discussing the exposed features to the public" implies that DNSBL providers should review and potentially alter the observable characteristics of their spam traps that were exploited for discovery. This could involve making them less predictable in their email acceptance policies or DNS configurations.

1. Email Provider and Website Administrator Actions:

• Implement DMARC for Outgoing Mail: Organizations should ensure their outgoing mail infrastructure fully supports and enforces DMARC with a policy of p=reject or p=quarantine. This makes it significantly harder for attackers to spoof their domains, reducing the effectiveness of spoofing-based Hades attacks.
• Monitor Outgoing Mail Logs: Regular monitoring of outgoing mail logs for unusual sending patterns, especially emails sent to unknown or suspicious domains, can help identify if internal or external attacks are being attempted.
• Secure Automated Email Systems: Websites offering subscription services, password resets, or other automated email triggers should implement CAPTCHAs, rate limiting, and other anti-abuse measures to prevent attackers from programmatically sending emails to identified spam traps. They should also validate recipient email addresses more rigorously where possible.
• Educate Users on Email Security: While not directly preventing Hades, general email security awareness can reduce the likelihood of internal accounts being compromised and used for internal Hades attacks.

1. General Security Posture:

• Regular DNSBL Monitoring: Organizations should proactively monitor their own IP addresses and domains across various DNSBLs. Tools exist that can check multiple blocklists simultaneously, allowing for rapid detection and response if an entity is blocklisted.
• Incident Response Plan: Have a clear incident response plan for blocklisting events, including procedures for contacting DNSBL providers, proving legitimacy, and mitigating impact.

The Hades attack underscores the need for continuous vigilance and adaptation in email security. The interconnected nature of the internet means that vulnerabilities in one system (DNSBLs) can have cascading effects on others (email deliverability, domain registration). A collaborative effort between researchers, DNSBL providers, and email system operators is essential to harden these foundational defenses against sophisticated manipulation.

Key Takeaways

• The Hades attack allows attackers to inject legitimate email servers and domains into DNS-based Blocklists (DNSBLs), severely disrupting email deliverability and potentially leading to domain deletion.
• Spam traps, critical components of DNSBLs, are not as secret as intended; researchers successfully identified thousands of spam traps, including 14,000 from Spamhaus, using publicly observable "exposed features."
• Attackers can blocklist IPs within two hours (as fast as three minutes for Spamhaus) and domains within six hours by tricking victim servers into sending emails to identified spam traps.
• The attack can target popular email providers (e.g., Hotmail, Gmail, Yahoo) through their automated email functions (subscriptions, password resets) and is exacerbated by some DNSBLs' lack of strict sender identity verification (SPF/DKIM).
• The most severe impact is the risk of domain deletion: four registries were found to use DNSBLs to delete blocklisted domains, affecting domains across 151 TLDs.
• Mitigation strategies include DNSBL providers diversifying capture intelligence, implementing stricter sender identity checks, and improving anomaly detection, while email providers should enforce DMARC and secure automated email systems.

About the Speaker(s)

Ruixuan Li is a researcher affiliated with Siha University. The talk at the NDSS Symposium focused on the security implications and manipulation risks associated with email blocklists, specifically detailing the "HADES Attack." Their work highlights a significant vulnerability in the foundational systems used to combat spam, demonstrating a deep understanding of email infrastructure and security protocols.