Route53 - CraftedSignal Threat Feed

AWS Route 53 Resolver Query Log Configuration Deleted

hello@craftedsignal.io — Tue, 14 May 2024 12:00:00 +0000

Amazon Route 53 Resolver query logs offer crucial insights into DNS activity across VPCs, encompassing lookups from EC2 instances, containers, and Lambda functions. The deletion of a query log configuration immediately halts DNS query and response logging for the associated VPC, creating a monitoring gap. This activity is often associated with defense evasion, where attackers attempt to remove logging to obscure their actions. This detection identifies successful invocations of the DeleteResolverQueryLogConfig API call within AWS CloudTrail logs. The scope of impact can range from individual VPCs to entire AWS environments, depending on the breadth of the deleted configuration. Defenders should prioritize investigation to determine whether the deletion was authorized and to identify potential malicious activity that may have been obscured.

Attack Chain

An attacker gains unauthorized access to an AWS account with sufficient privileges.
The attacker uses compromised credentials or an IAM role to interact with the AWS Management Console, CLI, or SDK.
The attacker identifies a Route 53 Resolver Query Log Configuration that is actively logging DNS queries for one or more VPCs.
The attacker invokes the DeleteResolverQueryLogConfig API call, specifying the ID of the target query log configuration.
AWS CloudTrail logs the DeleteResolverQueryLogConfig event with a successful outcome.
DNS query and response logging immediately ceases for the VPCs associated with the deleted configuration.
The attacker performs malicious activities, such as DNS tunneling or command and control communication, without being logged.
The attacker achieves their final objective, such as data exfiltration or system compromise, without detection via DNS logs.

Impact

A successful attack can lead to a significant reduction in DNS visibility across affected VPCs. Depending on the scope, this can impact a few resources or an entire AWS environment. The immediate consequence is the cessation of DNS query logging, which can obscure ongoing malicious activity, such as command-and-control communication, data exfiltration attempts, or reconnaissance efforts. The lack of DNS data hinders incident response and forensic investigations, making it difficult to identify the scope and impact of the attack.

Recommendation

Deploy the Sigma rule AWS Route 53 Resolver Query Log Configuration Deleted to your SIEM and tune for your environment.
Review IAM permissions and restrict the route53resolver:DeleteResolverQueryLogConfig action to a minimal set of privileged roles.
Enable AWS Config rules to detect and alert on missing or deleted Route 53 Resolver Query Log Configurations.
Investigate any deletion of Resolver Query Log Configurations to determine if it was authorized and corresponds to expected operational changes.
Monitor aws.cloudtrail.user_identity.arn for any unusual IAM roles or user accounts performing the deletion action as identified in the Sigma rule.
Re-create the deleted Resolver Query Log Configuration and re-associate it with the affected VPCs to restore DNS visibility immediately.

AWS Route 53 Domain Transfer Lock Disabled

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The disabling of a domain transfer lock within AWS Route 53 is a critical event that can signal malicious activity. The transfer lock is a security feature that prevents unauthorized transfer of a domain to another registrar or AWS account. An attacker who compromises an AWS account with sufficient permissions may disable this lock as a prerequisite for hijacking the domain, potentially leading to service disruption, data exfiltration, or brand damage. This activity is particularly concerning because domains underpin many critical services, including websites, email, and authentication mechanisms. The alert specifically triggers on the DisableDomainTransferLock event within AWS CloudTrail logs, providing visibility into this specific action. The targeted scope includes any AWS Route 53 domains managed by the organization.

Attack Chain

Initial Access: An attacker gains unauthorized access to an AWS account, possibly through compromised credentials or an IAM role with excessive privileges (T1078, T1098).
Privilege Escalation (if needed): The attacker escalates privileges within the AWS environment to gain the necessary permissions to manage Route 53 domains (T1068).
Discovery: The attacker enumerates the Route 53 domains associated with the compromised AWS account (T1082).
Disable Domain Transfer Lock: The attacker disables the domain transfer lock for a target domain by calling the DisableDomainTransferLock API (T1584.001).
Modify Contact Information: The attacker changes the contact information associated with the domain to gain control over authorization emails (T1586).
Initiate Domain Transfer: The attacker initiates a transfer of the domain to a registrar or AWS account under their control (T1584.001).
DNS Manipulation: After the transfer, the attacker modifies DNS records to redirect traffic to malicious servers, enabling phishing attacks or data theft (T1584.001).
Impact: The attacker disrupts services, steals sensitive information, or conducts further attacks leveraging the hijacked domain.

Impact

A successful domain hijacking can have severe consequences, including website defacement, email interception, and redirection of user traffic to malicious sites. Depending on the criticality of the domain, this could lead to significant financial losses, reputational damage, and legal liabilities. Organizations in all sectors are vulnerable, especially those heavily reliant on online services. The impact is amplified if the hijacked domain is used for authentication or other security-sensitive functions. Without proper detection and response, a domain hijacking can persist for an extended period, causing ongoing harm.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect instances of DisableDomainTransferLock events in AWS CloudTrail logs (logsource: aws.cloudtrail, event.action: DisableDomainTransferLock).
Immediately investigate any detected instances of disabled domain transfer locks, focusing on the user identity (aws.cloudtrail.user_identity.arn) and request parameters (aws.cloudtrail.request_parameters).
Enforce multi-factor authentication (MFA) for all AWS accounts, especially those with permissions to manage Route 53 domains.
Implement AWS Organizations service control policies (SCPs) to restrict domain-level actions to designated accounts, as mentioned in the overview.
Review and restrict domain-management permissions to the minimum set of authorized administrators as per the guide.
Monitor for modifications to contact details, attempted transfers, DNS record changes, or updates to hosted zones following lock disablement.

AWS Route 53 Private Hosted Zone Associated With Unauthorized VPC

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Attackers with sufficient AWS IAM permissions can associate a Route 53 private hosted zone with a Virtual Private Cloud (VPC) to expand the scope of internal DNS resolution, potentially intercepting, observing, or rerouting internal traffic. This activity allows adversaries to establish persistence or expand their visibility within an AWS environment. This association is achieved through the AssociateVPCWithHostedZone event. Defenders should monitor for unauthorized associations to prevent attackers from manipulating internal name resolution. The Elastic detection rule was last updated on April 10, 2026.

Attack Chain

The attacker gains unauthorized access to an AWS account, either through compromised credentials or exploiting a misconfigured IAM role, achieving initial access (TA0001).
The attacker enumerates existing Route 53 hosted zones and associated VPCs to identify potential targets for manipulation.
The attacker identifies a private hosted zone containing sensitive internal service records or privileged DNS information.
The attacker creates or compromises a VPC within the AWS environment or cross-account.
The attacker uses the AssociateVPCWithHostedZone API call to associate the attacker-controlled VPC with the targeted private hosted zone.
The attacker modifies DNS records within the associated hosted zone to redirect traffic to attacker-controlled resources.
The attacker intercepts internal traffic, observes service discovery processes, or redirects traffic to malicious services (TA0009).
The attacker maintains persistent access by manipulating internal name resolution (TA0003).

Impact

Successful exploitation allows attackers to intercept internal traffic, perform reconnaissance, and potentially gain access to sensitive data. The number of victims depends on the scope of the compromised hosted zone and the sensitivity of the data exposed. Targeted sectors could include any organization using AWS Route 53 for internal DNS resolution. If the attack succeeds, internal applications and services may become unavailable or compromised, leading to data breaches and service disruptions.

Recommendation

Deploy the "AWS Route 53 Private Hosted Zone Associated With a VPC" Sigma rule to your SIEM and tune for your environment to detect unauthorized VPC associations.
Review aws.cloudtrail.user_identity.arn and access_key_id to identify the actor initiating the association, as mentioned in the investigation steps.
Limit route53:AssociateVPCWithHostedZone permissions to specific administrative roles and require MFA for privileged accounts.
Monitor AWS CloudTrail logs for AssociateVPCWithHostedZone events to identify suspicious activity.

AWS Route 53 Domain Transferred to Another Account

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This threat brief addresses the unauthorized transfer of an AWS Route 53 domain to another AWS account. Route 53 is a scalable DNS web service, and control over a domain allows an attacker to modify DNS records, reroute traffic, and request certificates. The adversary could gain control by compromising an IAM user or leveraging long-lived credentials. Such a transfer can lead to persistence, traffic redirection, phishing attacks, or the staging of infrastructure for more extensive malicious operations. This activity is detected via CloudTrail logs when the TransferDomainToAnotherAwsAccount event is successfully invoked.

Attack Chain

An attacker gains unauthorized access to an AWS account through compromised credentials or IAM role exploitation.
The attacker identifies a target domain within the Route 53 service.
The attacker may disable the domain transfer lock using DisableDomainTransferLock.
The attacker initiates a domain transfer to an AWS account under their control using the TransferDomainToAnotherAwsAccount API call.
The transfer is successful, granting the attacker administrative control over the domain's DNS records.
The attacker modifies DNS records to redirect traffic to malicious servers they control.
The attacker sets up phishing sites or redirects legitimate traffic to a command-and-control infrastructure.

Impact

A successful Route 53 domain transfer enables an attacker to fully manage the domain's DNS resources, potentially leading to traffic redirection, service outages, or domain hijacking for phishing or command-and-control. While the exact number of victims and sectors targeted is unknown, unauthorized domain transfers can severely impact any organization relying on AWS for DNS services. This could disrupt service availability, compromise sensitive data through phishing, or enable persistent access to internal networks.

Recommendation

Deploy the Sigma rule AWS Route 53 Domain Transferred to Another Account to detect successful TransferDomainToAnotherAwsAccount events in AWS CloudTrail logs.
Monitor AWS CloudTrail logs for DisableDomainTransferLock events followed by TransferDomainToAnotherAwsAccount as it indicates a possible domain transfer preparation.
Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as aws:PrincipalArn and aws:MultiFactorAuthPresent as recommended in the AWS Knowledge Center – Security Best Practices.
Implement change-management tracking for domain ownership modifications, correlating with approved internal requests as noted in the overview.