Executive Summary

Cybercriminals regularly leverage popular dynamic domain name system (DDNS) or web hosting services to store and distribute their content. Threat actors leverage these for command and control (C2), malware distribution and phishing. This abuse has created the need for new detection methods for malicious subdomains.

DDNS and web hosting services often allow people to serve content from subdomains of a domain registered by the service provider. These subdomains offer the possibility of detecting malicious activity at the level of the DNS, but to do so is more difficult than detecting malicious registered domains.

Malicious domain detection has typically relied on information that may not be available for these subdomains of registered domains. For example, WHOIS information can reveal whether a domain has recently been registered, and (in some cases) who registered the domain. WHOIS information is not available for the subdomains of public apex domains, though.

Given this lack of information typically used to detect malicious domains, identifying malicious subdomains requires new methods. Palo Alto Networks has developed a system to detect malicious subdomains of public apex domains.

The detections generated by this detector are available to Palo Alto Networks Next-Generation Firewall customers with Cloud-Delivered Security Services, including DNS Security and Advanced URL Filtering.

Table of Contents

The DNS and Delegation
Malicious Domain Detection
Malicious Subdomains: A New Challenge
Detecting Malicious Subdomains of Public Apex Domains
Conclusion
Additional Resources

The DNS and Delegation

The DNS serves as the directory of the internet: a globally distributed database containing information about all the domain names that exist within the internet. To store and retrieve information for the vast number of domains in use, the DNS depends on delegation.

Various groups – including companies, governments and educational institutions – are responsible for managing portions of the DNS namespace. These groups control what domains are registered within the portion of the namespace they manage. They also maintain records for these domains and run servers that distribute those records.

For example, Verisign manages the .com top level domain (TLD). Verisign works with registrars to allow people to register names in the .com TLD, such as paloaltonetworks[.]com. It also maintains nameservers that refer people to where they can find information about these domains.

Similarly, Palo Alto Networks manages paloaltonetworks[.]com. We create subdomains, such as www[.]paloaltonetworks[.]com, and ensure DNS records for those subdomains are available in authoritative nameservers.

Delegation of responsibility for a domain usually happens when a domain is registered. Top level domains (TLDs) such as .com or .edu are, of course, special cases. The Internet Assigned Numbers Authority (IANA) delegates authority for TLDs through processes unique to TLDs. At lower levels of the DNS namespace, where most of the delegating action occurs, responsibility for a domain belongs to the party that registers the domain.

Typically only the party that registers a domain uses that domain (known as the apex domain) and its subdomains to provide content or services. For example, only Palo Alto Networks uses paloaltonetworks[.]com and its subdomains. For some registered domains, however, many parties may control subdomains. We refer to these domains as public apex domains. Figure 1 illustrates the two scenarios.

The case in which multiple parties control subdomains of a registered domain frequently occurs when the domain registrant runs a service that allows people to claim subdomains of its registered domain. Dynamic DNS providers and web hosting platforms frequently provide this option.

While the providers can – and often do – remove malicious domains and content, they are not creating the content or services represented by these subdomains. This arrangement creates challenges for detecting malicious subdomains.

Malicious Domain Detection

Malicious domain detection relies on various sources of information. First, we can observe attacks and blocklist the domains involved. This is a standard and helpful approach, but it only covers a portion of the threats evident in the DNS. Also, as a reactive measure, it may detect malicious domains too late to stop many attacks.

Other approaches look at the characteristics of observed domain names or their subdomains to determine if they are likely to have been generated by a domain generation algorithm (DGA), or used for DNS Tunneling. Still more can be learned from assessing a domain’s reputation.

Reputation comprises information about a domain such as age, usage patterns, popularity, what IP addresses it uses and what other domains use the same IP addresses. Newly registered domains or domains that have been dormant since registration (strategically aged domains) are treated with caution.

If a domain resolves to IP addresses in diverse networks over a short period, it is likely to be a fast-flux domain. These are just some of the ways in which a domain’s characteristics build its reputation and suggest whether it’s malicious. For subdomains of public apex domains, though, much of this information is not available or not helpful.

Malicious Subdomains: A New Challenge

DDNS is a technology that allows domains to map to different IP addresses over time without requiring network operators to manually change DNS records. Some providers of DDNS services allow people to manage subdomains of the provider’s registered domains.

For example, No-IP offers people the ability to create subdomains under 80 of its registered domains, including ddns[.]net and couchpotatofries[.]org. Similarly, FreeDNS enables users to claim subdomains of several thousand domains such as chickenkiller[.]com and undo[.]it. These free subdomains allow users who do not want to go to the expense or trouble of registering a domain to use the DNS for locating their servers.

Other services easing entry into the internet include various hosting platforms. Many well-known companies offer tools and resources that allow users to easily create and distribute content.

These providers may also offer people free subdomains from which to serve their content. For example, bloggers can share stories from subdomains of blogspot[.]com, researchers can showcase their projects at subdomains of github[.]io and companies building websites with Netlify can host those sites from subdomains of netlify[.]app.

Some providers of public apex domains have a large number of users and thus they have a non-trivial impact on the shape of DNS traffic. For example, in a day’s worth of Palo Alto Networks passive DNS data, the records for 93% of the top-level domains contained fewer than 87,000 unique registered domains. This is fewer than the number of subdomains seen for public apex domains such as github[.]io, netlify[.]app or ddns[.]net.

In the same passive DNS dataset, the number of subdomains for netlify[.]app was greater than the number of registered domains for the .tokyo and .work TLDs, both of which are in the top 10 TLDs for grayware use. Of course, these public apex domains only account for a tiny portion of the DNS traffic seen. Nonetheless, the fact that they have more subdomains than many TLDs demands that we consider their unique dynamics and how well we can characterize their subdomains.

This consideration becomes more pressing given attackers’ proclivity to use subdomains of public apex domains in their campaigns. Attackers regularly leverage DDNS to manage their infrastructure. Examples of this include C2 servers for Adwind malware and hosts used for COVID-19 related phishing campaigns.

Other malicious campaigns have incorporated various hosting services. For example, the Aggah campaign used Blogger to serve malicious scripts, and attackers have hosted various phishing campaigns on GitHub Pages.

Detecting which subdomains of public apex domains are malicious presents several unique challenges, as traditional approaches might not work or could require adjustments. Domain name characteristics are still somewhat helpful. For example, a random domain name like yjhtbgvfdcsdx[.]duckdns[.]org or a group of very similar domain names (e.g., nicetshirt171[.]blogspot[.]com, nicetshirt180[.]blogspot[.]com, nicetshirt186[.]blogspot[.]com) are inherently suspicious.

However, there are complications to using these characteristics for detection. Some providers might offer default algorithmically generated subdomain names that are DGA-like or very similar to each other. These characteristics would trigger many false positives if we used typical DGA detection approaches.

Establishing subdomain reputation is also more difficult than with registered domains. Information from WHOIS data does not help, as that pertains to the apex domain, not the subdomain itself.

Similarly, information about nameservers or sibling domains is not helpful, as the service provider manages the nameserver, and sibling domains are owned by thousands of different users. IP reputation might still help with DDNS domains, but for subdomains belonging to hosting providers, IP address information is practically useless. These subdomains resolve to the providers’ IP addresses which, like the nameservers, are shared by thousands of subdomains controlled by unrelated parties.

In short, traditional approaches to building domain reputation are insufficient to characterize subdomains of public apex domains. We need new approaches, and that is what Palo Alto Networks has developed.

Detecting Malicious Subdomains of Public Apex Domains

The system Palo Alto Networks has developed for detecting malicious subdomains of public apex domains uses the same basic principles as traditional malicious domain detection approaches. They check for suspicious lexical characteristics, and evaluate reputation. However, the methods for determining what is suspicious and for finding clues to reputation have changed.

Since many typical sources of information are no longer available, we have to be creative, consider a greater variety of inputs, and filter the inputs based on providers’ practices and policies. Putting these inputs together, we can start to characterize subdomains of public apex domains.

Our detectors currently focus on subdomains of a half dozen public apex domains chosen for evaluation largely based on how often their subdomains are reported by our other detectors. The detector identifies an average of over 300 new subdomains per day (shown in Figure 2).

Subdomains detected include those used for sites serving various scams, adult content, and other questionable or malicious content. Two of the more interesting cases we observed include a large-scale SMS phishing campaign and a free Robux scam.

Case One: SMS Phishing

For several months, our system has detected subdomains of duckdns[.]org involved in a campaign to distribute malware and steal credentials. The threat actor group Roaming Mantis runs the campaign, which targets mobile device users in several countries.

An attack typically starts with SMS phishing messages, and it is designed to have victims install the MoqHao malware (Android users) or to steal victims’ credentials (iPhone users). Attackers use geofencing to ensure only visitors from the target regions reach the landing page.

The attack regularly evolves. In mid-2022, we observed a portion of the campaign targeting au ID users. An au ID is an ID created by a Japanese telecommunications provider that allows users to easily perform actions such as accessing account information or making purchases.

Originally, the attack was different for Android and iPhone users, but after several weeks, we observed a change in the strategy. Figure 3 shows the structure of the campaign when we originally observed it (March 2022).

The attack started with a web page that automatically redirected users. On the second page, the user was redirected based on the user agent (shown in Figure 4).

If the user agent was iPhone, the visitor was redirected to a login page posing as an au ID login, but it was actually located at a duckdns[.]org DGA-like subdomain (shown in Figure 5a). If the user agent was Android, victims were redirected to a page where they are encouraged to install a service that was purported to detect annoying or fraudulent SMS and calls (shown in Figure 5b). Again, this page looked similar to those belonging to au ID, but it was located at a DGA-like duckdns[.]org subdomain.

By early June 2022, the attack had changed as shown in Figure 6, and victims using both Android and iPhone ended up at the same page.

In this version of the campaign, the page with the agent-based redirect still appeared in the chain, but both redirects led to pages with the same message. This page informed visitors they have an unpaid balance in electricity charges, and warned that their power would be stopped if they did not pay immediately (shown in Figure 7a).

Following the link to make the payment led to another page with a form in which visitors could fill in information for V-Preca (prepaid Visa) cards in order to make payments for the fake charges (shown in Figure 7b). The payments, of course, go to the attacker.

Case Two: Free Robux Generator

Since the middle of December 2022, our detection system has identified over 3,000 subdomains of a popular blog hosting service involved in a phishing campaign targeting Roblox users. Roblox’s platform is free, but users can purchase Roblox currency – called Robux – to access certain perks in the Roblox virtual world. Until recently, most Roblox users were under the age of 13, and children make up a large portion of the platform's users. Roblox’s site expressly states that there is no such thing as free Robux, but that has not stopped scammers from trying to convince people otherwise.

The blogs involved appear to be automatically generated using a few templates, and they include text or images related to Roblox (shown in Figure 8).

Scripts on these pages redirect automatically to bux[.]wellter[.]de. Visitors might need to click through browser warnings, but those who do arrive at a page offering free Robux (shown in Figure 9).

After running the generator, visitors are redirected again to a page at appinstallcheck[.]com listing several possible tasks users might need to perform in order to complete verification. These tasks include installing software, entering a contest to win money, or using a tool to monitor credit scores (shown in Figure 10).

Conclusion

Systems to detect malicious subdomains of public apex domains cannot simply employ the same approaches traditionally used to detect malicious registered domains. These subdomains have unique characteristics that require defenders to adapt methods to establish subdomain reputation. Developing such methods is an important task for security researchers and network defenders.

Palo Alto Networks assigns detected subdomains of public apex domains to the grayware category through our Cloud-Delivered Security Services. These subscriptions include DNS Security and Advanced URL Filtering.

Additional Resources

• Compromised or Attacker-Owned: A Large Scale Classification and Study of Hosting Domains of Malicious URLs - Usenix Security, 2021
• Building a Dynamic Reputation System for DNS - Usenix Security, 2010
• EXPOSURE: Finding Malicious Domains Using Passive DNS Analysis - ACM Transactions on Information and System Security, 2014