TotalCloud Insights: Crafting Effective Indicators of Compromise (IoCs) for Sub-domain Takeover Risk Detection

Anuj Kumar

Subdomain takeover poses a significant security threat in cloud environments. It occurs when a subdomain of a domain (e.g., subdomain.example.com) inadvertently resolves to an external service no longer under the organization’s control. These orphaned subdomains provide attackers with a foothold for deploying malicious activities like phishing, malware distribution, and data exfiltration. This oversight, often unintentional, creates blind spots in security coverage.

Keytos Research reports discovering over 15,000 vulnerable subdomains monthly in Azure, yet only 2% of organizations actively address this problem. Even major entities like Microsoft are not immune; Keytos identified 700+ vulnerable subdomains associated with Microsoft, underscoring that even large organizations face subdomain vulnerabilities.

Impact of Sub-domain Takeover

  1. Data Breaches: Subdomain takeovers can lead to unauthorized access, allowing attackers to breach sensitive data and compromise user privacy and organizational integrity.
  2. Phishing Attacks: Attackers can create convincing phishing sites using hijacked subdomains, tricking users into divulging sensitive information, or installing malware.
  3. Reputation Damage: Subdomain takeovers can tarnish an organization’s reputation, eroding customer trust and confidence, especially if exploited for malicious purposes.
  4. Financial Loss: Incidents may lead to financial repercussions, including legal costs, fines, and loss of revenue due to downtime or diminished customer loyalty following a security breach.
  5. SEO Manipulation: Attackers can use compromised subdomains to manipulate search engine rankings, affecting a website’s visibility and credibility and impacting online business opportunities.

Sub-domain Takeovers: Recent Exploit Overview

A significant security incident occurred within the NPM ecosystem due to the NPM subdomain takeover. During this incident, an attacker exploited a misconfigured DNS record for the domain assets.npmjs.com, gaining control of an S3 bucket hosting the NPM package registry. This breach enabled the attacker to inject malicious code into widely used JavaScript libraries, which were subsequently downloaded by millions of developers.

The initial observation of the attack focused on a npm package named “bignum,” which, up to version 0.13.0, relied on an Amazon S3 bucket to download pre-built binary versions of an addon called “node-pre-gyp” during installation. A GitHub advisory published on May 24, 2023, revealed that these binaries were published on an expired S3 bucket, which a malicious third party had claimed. As unsuspecting users downloaded the affected package, malware capable of exfiltrating data from their computers was delivered, exploiting the opportunity presented by the once-active S3 bucket.

This incident underscores the critical importance of robust security measures and continuous vigilance in safeguarding software repositories and dependencies against subdomain takeover attacks and other malicious activities. 

Figure 1: Static S3 website sub-domain takeover

Let’s discuss the above scenarios in a static S3 website subdomain takeover:

Ideal Scenario:

  1. Static Website Creation: An organization creates a static S3 website.
  2. DNS Record Configuration: The organization configures a “CNAME” type DNS record in Route 53 to point to this static S3 website to subdomain “subdomain.domain.com.”
  3. User Access to Genuine Data: Users visit “subdomain.domain.com” to access legitimate content hosted on the organization’s S3 bucket.

Subdomain Takeover Case:

  1. Bucket Deletion: At some point, the organization’s developer deletes the S3 bucket, but no action is taken to update the DNS record entry.
  2. Attacker’s Visit: An attacker discovers the vulnerable URL “subdomain.domain.com” and accesses it.
    1. NoSuchBucket Error: Upon visiting, the attacker receives a “NoSuchBucket” error, indicating that the S3 bucket does not exist.
    2. Attacker’s Bucket Creation: Seizing the opportunity, the attacker creates an S3 bucket named “subdomain.domain.com” and hosts malicious content within it.
  3. User Access to Attacker’s Content: When users attempt to access “subdomain.domain.com,” they are redirected to the attacker’s bucket, consuming malicious resources.
  4. User Impact: Users experience various adverse effects due to the attacker’s content, such as security risks, data exposure, or compromised functionality.
  5. Organizational Impact: The organization can suffer significant consequences, including damage to its reputation, legal liabilities, and service disruptions.
  6. Remediation and Recovery: To address the situation, the organization must remove the DNS record to prevent further abuse of this subdomain.

Exploring the Process of Establishing an IoC/Control in TotalCloud

Qualys TotalCloud, a cloud-native security solution, provides maximum security coverage through agent and agentless options, ensuring accurate detection of vulnerabilities. It centralizes workload and cloud posture data, offering specific insights to reduce overall risk and automating remediation for high-risk assets. Furthermore, it proactively identifies and addresses security issues before deployment, enhancing overall cybersecurity measures.

Qualys Flow is one of the offerings of TotalCloud, which is used for no-code automated workflow creation capability that allows you to build workflows known as QFlows. It provides end-to-end orchestration of detection and remediation processes within the Qualys Cloud Platform and from your cloud infrastructure, such as AWS, Azure, and GCP. Qualys Flow visualizes the logical flow of events, data, and actions in the form of nodes, each delivering a specific function in the detection, analysis, or remediation chain. QFlows can be created directly in the UI by dragging and dropping nodes and configuring them as needed.

Let’s walk through two end-to-end security examples using Qualys Flow.

Using Qualys Flow To Detect Subdomain Takeover With Route 53 CNAME Record to Non-Existent AWS S3 Bucket  

A subdomain takeover is a situation where an attacker gains the ability to host content on a subdomain managed by a third-party service that isn’t currently being utilized by its rightful owner. One frequently encountered example of subdomain takeovers involves Amazon S3 buckets and Route 53 DNS records.

In a subdomain takeover scenario, if a subdomain (e.g., subdomain.example.com) is configured as a CNAME record pointing to a non-existent S3 bucket (or a deleted), and an attacker can create that non-existent bucket in their own AWS account, they can essentially take over the subdomain.

Figure 2: Qualys Flow visualizes complex workflows in its intuitive UI

All QFlows begin with a Trigger node, which specifies what event triggers the workflow. For this QFlow, we have configured the Trigger node to TotalCloud.

Our workflow then proceeds with the following steps:

  1. Fetching S3 Buckets: We’ve set up a node to retrieve a list of all the S3 buckets.
  2. Retrieving CNAME Records: We extract all “CNAME” type DNS records.
  3. Custom Node for Bucket Extraction: We introduce a custom node to extract the bucket name from the URL. JavaScript code is utilized to identify the S3 bucket name from static S3 website URLs.
  4. Verifying Bucket Existence: We cross-checked the acquired bucket names with Route 53 “CNAME” records to ensure subdomain security. If a bucket does not exist, this implies a vulnerability to subdomain takeover. Download this Qflow template for importing into your TotalCloud account.
  5. In the event of an attack request to such a URL, the response will mirror the following outcome:
  1. Following these steps, the attacker can create a new bucket and host the content of their choice within it.

Qualys Flow also integrates with Qualys TotalCloud. You can create a custom control in TotalCloud by linking it to a QFlow. The custom control can help monitor and enforce this security control. When a resource fails due to the absence of the specified bucket in your AWS account, it creates an opportunity for attackers to create a subdomain associated with that bucket. This vulnerability can be exploited to launch supply chain attacks and other malicious activities, leading to a substantial risk to the organization’s reputation and causing disruptions to the user experience.

To address this issue, one effective remediation approach is to implement a workflow designed to prevent subdomain takeover.

How Qualys Flow Can Be Used To Detect Subdomain Takeover of “A” Type Record in Route 53 

Subdomain takeover vulnerabilities materialize when a subdomain directs to an IP (Internet Protocol) address or a resource outside the control of the domain owner. This risk persists in the case of dynamic public IP addresses being used. When instances rely on dynamic public IP addresses, a subdomain takeover could transpire if a subdomain points to a terminated instance and the IP address is reassigned to a different instance controlled by a third party.

Identifying and addressing such DNS records is a critical concern. Let’s explore how we can detect or create IoC related to subdomain takeover using Qualys Flow.

In the workflow described above, we follow a series of steps:

  1. Fetching Elastic IPs Details: Initially, we retrieve the details of the Elastic IPs.
  2. Retrieve Route 53 Details: Next, we fetch Route 53 details, focusing on records associated with IPv4 IP addresses.
  3. Comparison of Elastic IPs and Route 53 Details: We compare the information obtained from Elastic IPs with that from Route 53 records.
  4. TotalCloud Node for Dynamic IPv4: As a result of this comparison, we identify nodes using dynamic IPv4 addresses using the TotalCloud Node. Download this Qflow template for importing into your TotalCloud account.

The outcome of this Qflow includes a clear understanding of which nodes are utilizing dynamic IPv4 addresses, enabling proactive management and potential mitigation of subdomain takeover risks within your infrastructure.

For Importing Qflow in TotalCloud, please refer to: https://docs.qualys.com/en/qflow/latest/managing_qflows/importing_qflows.htm

For creating control from Qflow, please refer to: https://docs.qualys.com/en/cloudview/latest/controls/Create_Customized_Controls_using_QFlows.htm

Conclusion

Cloud misconfigurations can lead to significant economic losses and damage an organization’s reputation. Establishing Indicators of Compromise (IoC) is crucial for preventing sub-domain takeovers and other security risks. Qualys TotalCloud allows users to create IoC and controls tailored to their needs, offering high customization to meet various requirements. This flexibility ensures that the controls align with specific needs. Users can conveniently monitor the status of these controls in the posture tab of TotalCloud after implementation.

Contributors

  • Rahul Pareek, Signature QA Engineer, Cloud Security Compliance, Qualys
  • Shilpa Gite, Manager, Cloud Security Compliance, Qualys
Share your Comments

Comments

Your email address will not be published. Required fields are marked *