diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml index 942e042e88b..cd6eb4c53e3 100644 --- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml +++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml @@ -2,59 +2,96 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2025/01/10" +updated_date = "2025/12/10" [rule] author = ["Elastic"] description = """ -Identifies when a Route53 Resolver Query Log Configuration is deleted. When a Route53 Resolver query log configuration -is deleted, Resolver stops logging DNS queries and responses for the specified configuration. Adversaries may delete -query log configurations to evade detection or cover their tracks. +Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical +visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and +other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the +associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade +security monitoring capabilities. """ -false_positives = ["Legitimate deletion of Route53 Resolver Query Log Configuration by authorized personnel."] -from = "now-60m" +false_positives = [ + """ + Query log configuration deletions may occur during legitimate networking changes, logging pipeline updates, or + infrastructure redesign. Confirm the activity aligns with expected operations before taking action. + """, +] +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail*"] -interval = "10m" language = "kuery" license = "Elastic License v2" -name = "Route53 Resolver Query Log Configuration Deleted" -note = """ -## Triage and analysis - -### Investigating Route53 Resolver Query Log Configuration Deleted - -This rule detects when a Route53 Resolver Query Log Configuration is deleted. Deleting these configurations stops the logging of DNS queries and responses, which can significantly impede network monitoring and compromise security visibility. Adversaries may delete these configurations to evade detection, remove evidence, or obscure their activities within a network. - -Adversaries target Route53 Resolver query log configurations because these logs can contain evidence of malicious domain queries or responses. By deleting these logs, an adversary can prevent the capture of information that could reveal unauthorized network activities, aiding in avoiding detection and thwarting incident response efforts. - -#### Possible Investigation Steps - -- **Review the Deletion Details**: Examine the CloudTrail logs to identify when and by whom the deletion was initiated. - - Check the `event.action` and `user_identity` elements to understand the scope and authorization of the deletion. -- **Contextualize with User Actions**: Assess whether the deletion aligns with the user’s role and job responsibilities. - - Investigate if similar modifications have occurred recently that could suggest a pattern or broader campaign. -- **Analyze Access Patterns and Permissions**: Verify whether the user had the appropriate permissions to delete log configurations. - - Investigate any recent permission changes that might indicate role abuse or credentials compromise. -- **Correlate with Other Security Incidents**: Look for related security alerts or incidents that could be connected to the log deletion. - - This includes unusual network traffic, alerts from other AWS services, or findings from intrusion detection systems. -- **Interview the Responsible Team**: If the deletion was initiated by an internal team member, confirm their intent and authorization to ensure it was a legitimate action. - -### False Positive Analysis - -- **Legitimate Administrative Actions**: Confirm that the deletion was part of scheduled IT operations or network management activities, possibly linked to maintenance or infrastructure updates. Validate this action against change management records or through interviews with relevant personnel. - -### Response and Remediation - -- **Restore Logs if Feasible**: If the deletion was unauthorized, consider restoring the configuration from backups to ensure continuous visibility into DNS queries. -- **Review and Tighten Permissions**: Ensure that only authorized personnel have the capability to delete critical configurations. - - Adjust AWS IAM policies to reinforce security measures. -- **Enhance Monitoring of Log Management**: Implement or enhance monitoring rules to detect and alert on unauthorized changes to logging configurations, focusing on critical deletions. -- **Conduct Comprehensive Security Review**: If the deletion is verified as malicious, initiate a thorough security assessment to identify any further unauthorized changes or ongoing malicious activities. - -### Additional Information - -For detailed instructions on managing Route53 Resolver and securing its configurations, refer to the [Amazon Route53 Resolver documentation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html). - +name = "AWS Route 53 Resolver Query Log Configuration Deleted" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating AWS Route 53 Resolver Query Log Configuration Deleted + +Route 53 Resolver query logs provide essential telemetry for DNS visibility across AWS environments. Deleting a Resolver Query Log Configuration immediately halts DNS logging for one or more VPCs, creating a significant monitoring gap. Adversaries may intentionally delete these configurations to hide malicious activity. This rule detects successful invocations of `DeleteResolverQueryLogConfig`. + +### Possible investigation steps + +**Validate the actor and request origin** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. Confirm whether the identity normally manages Route53 Resolver resources or VPC-level DNS configuration. +- Examine `source.ip`, `source.address`, `source.geo` fields and `user_agent.original` to determine whether the request originated from an expected network path or automation role. Whether API calls were made via console, CLI, SDK, or custom tooling. + +**Understand what was deleted and the impacted environment** +- Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to identify the Query Log Configuration ID, Associated VPCs and destinations (e.g., CloudWatch Log Group, S3 bucket, Kinesis stream). +- Determine whether these VPCs support production workloads, contain regulated or sensitive data, host internet-facing or privileged workloads (e.g., EKS clusters, directory services, bastion hosts). + +**Correlate for intent and related activity** +- Use `@timestamp` to correlate the deletion with: + - Prior `PutResolverQueryLogConfig` or `AssociateResolverQueryLogConfig` modifications. + - IAM permission changes or STS session activities. + - Recent DNS anomalies if logs were active prior to deletion. +- Pivot on the same `aws.cloudtrail.user_identity.arn` to identify: + - Additional logging-related tampering (CloudTrail, VPC Flow Logs, S3 server access logs). + - Resource isolation or privilege escalation attempts. + - Suspicious EC2, Lambda, or container workload behavior. + +**Validate operational context** +- Check whether a change request, maintenance window, or migration task was underway that could explain the deletion. +- Confirm with networking, SRE, or platform engineering teams whether a logging pipeline redesign was in progress, a deprecated log config was intentionally removed, infrastructure-as-code (IaC) automation recently applied updates that removed the configuration. + +### False positive analysis + +- **Legitimate network and logging redesign** + - Deletions performed during planned VPC migrations, resolver logging pipeline upgrades, or CloudWatch/S3 restructuring may be benign. +- **Expected IaC behavior** + - Terraform, CloudFormation, or CDK stacks may destroy and recreate logging configurations during updates. + Validate pipeline activity and automation roles to avoid noise. + +### Response and remediation + +**Contain and restore visibility** +- If unauthorized activity is suspected: + - Immediately re-create the Resolver Query Log Configuration. + - Re-associate the configuration with the affected VPCs to restore DNS visibility. + - Verify that CloudWatch Log Groups or S3 destinations have not been deleted or altered. + +**Investigate access and scope of impact** +- Review IAM permissions assigned to the actor: + - Identify whether privilege escalation or role compromise occurred. + - Validate that other high-impact logging or monitoring configurations (CloudTrail, VPC Flow Logs, GuardDuty) remain intact. +- Perform a DNS-focused threat hunt: + - Analyze prior logged queries for indicators of malware, C2 infrastructure, or suspicious domains before the logging gap. + +**Strengthen defensive controls** +- Restrict sensitive operations by: + - Limiting `route53resolver:DeleteResolverQueryLogConfig` to a small number of privileged roles. + - Adding IAM condition keys to constrain deletion operations by source IP, region, or principal ARN. +- Enable AWS Config or Security Hub controls that: + - Detect missing or deleted query log configurations. + - Enforce continuous logging for critical VPCs. + +### Additional information +- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** +- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** +- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)** """ references = [ "https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html", @@ -66,7 +103,7 @@ tags = [ "Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", - "Data Source: Amazon Route53", + "Data Source: AWS Route 53", "Use Case: Log Auditing", "Resources: Investigation Guide", "Tactic: Defense Evasion", @@ -75,8 +112,10 @@ timestamp_override = "event.ingested" type = "query" query = ''' -event.dataset:aws.cloudtrail and event.provider: route53resolver.amazonaws.com - and event.action: DeleteResolverQueryLogConfig and event.outcome: success +event.dataset: aws.cloudtrail + and event.provider: route53resolver.amazonaws.com + and event.action: DeleteResolverQueryLogConfig + and event.outcome: success ''' @@ -98,3 +137,21 @@ id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +] + diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml index f74ae5c1bea..80a9fefa57d 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml @@ -2,24 +2,25 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/10" [rule] author = ["Elastic", "Austin Songer"] description = """ -Identifies when a transfer lock was removed from a Route 53 domain. It is recommended to refrain from performing this -action unless intending to transfer the domain to a different registrar. +Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being +moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard +against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a +precursor to unauthorized domain transfer, takeover, or service disruption. """ false_positives = [ """ - A domain transfer lock may be disabled by a system or network administrator. Verify whether the user identity, user - agent, and/or hostname should be making changes in your environment. Activity from unfamiliar users or hosts should - be investigated. If known behavior is causing false positives, it can be exempted from the rule. + A domain transfer lock may be intentionally disabled by an authorized administrator to prepare for a planned domain + migration or registrar change. Confirm that the action aligns with an approved change request. You may exempt known + administrative accounts involved in routine domain operations to reduce noise. """, ] -from = "now-60m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route 53 Domain Transfer Lock Disabled" @@ -30,58 +31,100 @@ note = """## Triage and analysis ### Investigating AWS Route 53 Domain Transfer Lock Disabled -AWS Route 53's domain transfer lock is a security feature that prevents unauthorized domain transfers. Disabling this lock can expose domains to hijacking risks. Adversaries might exploit this by transferring domains to gain control over web traffic or disrupt services. The detection rule monitors successful lock disablement events, alerting analysts to potential unauthorized actions, thereby aiding in maintaining domain integrity. +This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock +prevents unauthorized domain transfers, and disabling it is an uncommon operation outside of planned migrations. Because +domains often underpin production workloads (web, API, authentication, email), unauthorized transfer lock changes may +indicate adversary preparation for domain hijacking or service disruption. + +This event should be treated with high urgency whenever it occurs unexpectedly. ### Possible investigation steps -- Review the AWS CloudTrail logs for the specific event.action: DisableDomainTransferLock to identify the user or service account responsible for the action. -- Check the event.provider: route53.amazonaws.com logs to gather additional context about the domain affected and any related activities around the time of the lock disablement. -- Verify the event.outcome: success to confirm that the lock was indeed successfully disabled and not just attempted. -- Investigate the account activity of the user identified in the logs to determine if there are any other suspicious actions or patterns that could indicate unauthorized access. -- Assess whether there was a legitimate business need for the domain transfer lock to be disabled, such as a planned domain transfer, by consulting with relevant stakeholders or reviewing change management records. -- Evaluate the current security posture of the affected domain, ensuring that other security measures are in place to mitigate potential risks from the lock being disabled. +- **Review the actor** + - Examine `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to confirm who + initiated the change. Validate whether this identity normally performs domain-management tasks. + +- **Analyze the request context** + - Review `aws.cloudtrail.request_parameters` to identify which domain was affected. + - Confirm no corresponding `operation=TransferDomainToAnotherAwsAccount` or registrar-level modifications occurred + shortly before or after the lock was disabled. + - Note the timestamp and evaluate whether the change occurred during maintenance windows or outside business hours. + +- **Evaluate activity surrounding the lock disablement** + - Look for subsequent events such as modifications to contact details, attempted transfers, DNS record changes, or updates to hosted zones. Correlate with unusual IAM role usage, newly issued access keys, or anomalous login behavior. + +- **Validate intent with responsible teams** + - Confirm whether stakeholders (network operations, domain owners, infrastructure leads) initiated or approved the + transfer lock disablement. If unmanaged or unexpected, treat this as a potentially malicious action. ### False positive analysis -- Routine domain management activities by authorized personnel can trigger alerts when they intentionally disable the transfer lock for legitimate domain transfers. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list. -- Scheduled domain transfers as part of business operations may result in false positives. Implement a process to document and pre-approve such transfers, allowing security teams to quickly verify and dismiss these alerts. -- Automated scripts or tools used for domain management might inadvertently disable the transfer lock during updates or maintenance. Ensure these tools are configured correctly and include logging to track their actions, allowing for quick identification and exclusion of benign activities. -- Changes in domain ownership or restructuring within the organization can lead to legitimate transfer lock disablement. Establish a communication protocol between IT and security teams to notify them of such changes in advance, reducing unnecessary alerts. +- **Authorized transfer preparation** + - The most common legitimate case is preparation for a planned transfer of ownership or registrar migration. Ensure the + change aligns with a ticketed and approved operation. + +- **Internal domain restructuring** + - Organizational changes (e.g., merging AWS accounts, consolidating DNS assets) may require disabling the lock. Check + for documented work items or migration plans. + +- **Automated tooling** + - Rare but possible: Some internal automation used for domain lifecycle management may disable the lock as part of an + update. Validate that any automation using administrative API credentials is documented and approved. ### Response and remediation -- Immediately verify the legitimacy of the domain transfer request by contacting the domain owner or the responsible team to confirm if the action was intentional. -- If the transfer lock was disabled without authorization, re-enable the transfer lock on the affected domain to prevent any unauthorized transfer attempts. -- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access or suspicious activities related to the domain management account. -- Reset credentials and enforce multi-factor authentication (MFA) for all accounts with access to AWS Route 53 to prevent further unauthorized actions. -- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. -- Escalate the incident to higher management and legal teams if there is evidence of malicious intent or if the domain is critical to business operations. -- Implement additional monitoring and alerting for any future changes to domain transfer locks to ensure rapid detection and response to similar threats. +- **Re-enable the transfer lock immediately if unauthorized** + - Restore the lock from Route 53 to prevent any pending or future unauthorized transfer attempts. + +- **Contain potential credential compromise** + - If the action is suspicious, rotate credentials for the user or role involved and enforce MFA. -## Setup +- **Audit for related domain-level modifications** + - Review CloudTrail logs for: + - attempted domain transfers, + - contact profile changes, + - hosted zone modifications, + - DNS record updates, + - IAM privilege escalations. -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +- **Engage internal owners** + - Notify domain owners, infosec leadership, and operations teams; determine business impact and next steps. + +- **Strengthen governance** + - Limit domain-management permissions to the minimum set of authorized administrators. + - Consider implementing AWS Organizations service control policies (SCPs) to prevent domain-level actions except + through designated accounts. + +### Additional information +- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** +- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** +- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)** +""" references = [ "https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html", "https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_DisableDomainTransferLock.html", ] -risk_score = 21 +risk_score = 73 rule_id = "12051077-0124-4394-9522-8f4f4db1d674" -severity = "low" +severity = "high" tags = [ "Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", - "Data Source: AWS Route53", + "Data Source: AWS Route 53", "Use Case: Asset Visibility", "Tactic: Persistence", + "Tactic: Resource Development", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "query" query = ''' -event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com and event.action:DisableDomainTransferLock and event.outcome:success +event.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: DisableDomainTransferLock + and event.outcome: success ''' @@ -99,9 +142,36 @@ name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1584" +name = "Compromise Infrastructure" +reference = "https://attack.mitre.org/techniques/T1584/" +[[rule.threat.technique.subtechnique]] +id = "T1584.001" +name = "Domains" +reference = "https://attack.mitre.org/techniques/T1584/001/" + + [rule.threat.tactic] -id = "TA0006" -name = "Credential Access" -reference = "https://attack.mitre.org/tactics/TA0006/" +id = "TA0042" +name = "Resource Development" +reference = "https://attack.mitre.org/tactics/TA0042/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +] diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml index a3fe3ae7c10..c46c8142ede 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml @@ -2,22 +2,27 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/10" [rule] author = ["Elastic", "Austin Songer"] -description = "Identifies when a request has been made to transfer a Route 53 domain to another AWS account." +description = """ +Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes +administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, +request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users +or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or +stage infrastructure for broader attacks. This rule detects successful domain transfer requests. +""" false_positives = [ """ - A domain may be transferred to another AWS account by a system or network administrator. Verify whether the user - identity, user agent, and/or hostname should be making changes in your environment. Domain transfers from unfamiliar - users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the - rule. + Internal account restructuring, mergers and acquisitions, or legitimate ownership transfers between business units + may involve transferring DNS domains to other AWS accounts. Confirm the transfer is approved and documented in + change management processes before taking action. Transfers performed by unfamiliar identities, originating from + atypical locations, or outside expected maintenance windows should be investigated. """, ] -from = "now-60m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route 53 Domain Transferred to Another Account" @@ -28,55 +33,98 @@ note = """## Triage and analysis ### Investigating AWS Route 53 Domain Transferred to Another Account -AWS Route 53 is a scalable domain name system (DNS) web service designed to route end-user requests to internet applications. Transferring a domain to another AWS account can be legitimate but may also indicate unauthorized access or account manipulation. Adversaries might exploit this to gain persistent control over a domain. The detection rule monitors successful domain transfer requests, flagging potential misuse by correlating specific AWS CloudTrail events, thus aiding in identifying unauthorized domain transfers. +Transferring a Route 53 domain to another AWS account is a high-impact administrative action. A successful transfer enables the +recipient account to fully manage the domain and all associated DNS resources. Unauthorized transfers can result in loss of +visibility and control, traffic redirection, service outages, or domain hijacking for phishing, credential harvesting, or command-and-control. + +This rule detects successful calls to `TransferDomainToAnotherAwsAccount`. These events are rare and should be considered +high-risk unless explicitly documented and approved. ### Possible investigation steps -- Review the AWS CloudTrail logs to identify the specific event with event.action:TransferDomainToAnotherAwsAccount and event.outcome:success to gather details about the domain transfer request. -- Verify the identity of the AWS account to which the domain was transferred by examining the event details, including the account ID and any associated user or role information. -- Check the AWS account's activity history for any unusual or unauthorized access patterns around the time of the domain transfer event. -- Contact the domain's original owner or administrator to confirm whether the transfer was authorized and legitimate. -- Investigate any recent changes in IAM policies or permissions that might have allowed unauthorized users to initiate the domain transfer. -- Assess the potential impact of the domain transfer on your organization's operations and security posture, considering the domain's role in your infrastructure. +- **Identify the actor and authentication context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the transfer. Determine whether the actor typically performs Route 53 administrative actions or if this represents anomalous behavior. -### False positive analysis +- **Review request details and target account** + - Inspect `aws.cloudtrail.request_parameters` for: `DomainName`, `AccountId` receiving the transfer, Request tokens or validation parameters. Validate whether the destination AWS account is recognized, trusted, or documented in ownership transfer procedures. + +- **Assess environment and timing** + - Compare `@timestamp` against maintenance windows, deployment pipelines, or approved domain operations. Review the region and endpoint used; domain transfers occurring from unexpected regions may indicate unauthorized access. + +- **Analyze source and execution context** + - Review `source.ip`, `source.geo.country_iso_code`, and `user_agent.original` to determine: + - If the request originated from known networks, Whether it matches typical administrator access patterns or if suspicious automation tools, outdated SDK versions, or unknown agents were used. -- Routine domain transfers between accounts within the same organization can trigger alerts. To manage this, create exceptions for known internal account transfers by whitelisting specific account IDs involved in regular transfers. -- Scheduled domain management activities by IT teams may result in false positives. Coordinate with IT to document and schedule these activities, then exclude them from alerts during these periods. -- Automated scripts or tools used for domain management might inadvertently trigger alerts. Identify these scripts and their associated user accounts, and configure exceptions for these known, benign activities. -- Transfers related to mergers or acquisitions can be mistaken for unauthorized actions. Ensure that such events are communicated to the security team in advance, allowing them to temporarily adjust monitoring rules to accommodate these legitimate transfers. +- **Correlate with broader activity** + - Pivot on the same IAM principal or access key ID to identify: + - Recent IAM policy changes or privilege escalation + - `DisableDomainTransferLock`, which normally precedes domain transfers + - AWS console sign-ins from new geolocations or ASNs + - API calls involving certificate requests, hosted zone changes, or DNS record edits + - Look for evidence of lateral movement or credential theft preceding the transfer. + +- **Validate with business owners** + - Confirm with domain owners, development teams, or asset managers whether The transfer was intentional. + +### False positive analysis +- **Expected domain migrations** + - Organizations with multi-account strategies may transfer domains between operational, security, or sandbox accounts. +- **Business events** + - Mergers, acquisitions, or contractual transitions between managed service providers often involve bulk domain transfers. +- **Automated administrative tooling** + - Domain lifecycle automation or infrastructure-as-code pipelines may trigger transfers if misconfigured. + ### Response and remediation -- Immediately revoke any unauthorized access to the AWS account by changing the credentials and access keys associated with the account where the domain was transferred. -- Contact AWS Support to report the unauthorized domain transfer and request assistance in reversing the transfer if it was not authorized. -- Review AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts around the time of the domain transfer. -- Implement multi-factor authentication (MFA) for all AWS accounts to enhance security and prevent unauthorized access. -- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to transfer domains. -- Notify relevant stakeholders, including IT security teams and domain administrators, about the incident and the steps being taken to remediate it. -- Enhance monitoring and alerting for similar events by configuring additional AWS CloudWatch alarms or integrating with a Security Information and Event Management (SIEM) system to detect future unauthorized domain transfer attempts. +- **Contain and revoke access** + - If unauthorized, immediately invalidate the IAM session or access keys used in the transfer. + - Rotate credentials for the implicated IAM user or role and require MFA for privileged operations. -## Setup +- **Reverse or halt the transfer** + - Contact AWS Support as soon as possible to request assistance reversing or blocking the transfer if it was not approved. + - Re-enable transfer lock (`DisableDomainTransferLock=false`) to prevent further modifications. -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +- **Investigate the extent of compromise** + - Review CloudTrail to identify all actions performed by the actor before and after the transfer. + - Check for additional changes to hosted zones, DNS records, certificates, or registrar contact details. + +- **Restore operational integrity** + - Validate DNS routing, certificate issuance, and application endpoints for signs of redirection or tampering. + - Communicate with impacted teams and external stakeholders if customer-facing domains were affected. + +- **Hardening and long-term improvements** + - Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as `aws:PrincipalArn` and `aws:MultiFactorAuthPresent` + - Consider SCPs to block domain-transfer APIs in production accounts. + - Add change-management tracking for domain ownership modifications. + +### Additional information +- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** +- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** +- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)** +""" references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"] -risk_score = 21 +risk_score = 73 rule_id = "2045567e-b0af-444a-8c0b-0b6e2dae9e13" -severity = "low" +severity = "high" tags = [ "Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", - "Data Source: AWS Route53", + "Data Source: AWS Route 53", "Use Case: Asset Visibility", "Tactic: Persistence", + "Tactic: Resource Development", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "query" query = ''' -event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com and event.action:TransferDomainToAnotherAwsAccount and event.outcome:success +event.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: TransferDomainToAnotherAwsAccount + and event.outcome: success ''' @@ -94,9 +142,37 @@ name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1584" +name = "Compromise Infrastructure" +reference = "https://attack.mitre.org/techniques/T1584/" +[[rule.threat.technique.subtechnique]] +id = "T1584.001" +name = "Domains" +reference = "https://attack.mitre.org/techniques/T1584/001/" + + [rule.threat.tactic] -id = "TA0006" -name = "Credential Access" -reference = "https://attack.mitre.org/tactics/TA0006/" +id = "TA0042" +name = "Resource Development" +reference = "https://attack.mitre.org/tactics/TA0042/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +] diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml index 675899d8872..df804db5ca6 100644 --- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml +++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml @@ -2,80 +2,127 @@ creation_date = "2021/07/19" integration = ["aws"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/10" [rule] -author = ["Austin Songer"] -description = "Identifies when a Route53 private hosted zone has been associated with VPC." +author = ["Austin Songer", "Elastic"] +description = """ +Identifies when an AWS Route 53 private hosted zone is associated with a new Virtual Private Cloud (VPC). Private hosted +zones restrict DNS resolution to specific VPCs, and associating additional VPCs expands the scope of what networks can +resolve internal DNS records. Adversaries with sufficient permissions may associate unauthorized VPCs to intercept, +observe, or reroute internal traffic, establish persistence, or expand their visibility within an AWS environment. +""" false_positives = [ """ - A private hosted zone may be asssociated with a VPC by a system or network administrator. Verify whether the user - identity, user agent, and/or hostname should be making changes in your environment. If known behavior is causing - false positives, it can be exempted from the rule. + Private hosted zones may be legitimately associated with VPCs by network or infrastructure administrators. Verify + whether the user identity, user agent, and source IP address align with expected administrative behavior. Known and + authorized associations may be exempted to reduce noise. """, ] -from = "now-60m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -interval = "10m" language = "kuery" license = "Elastic License v2" -name = "AWS Route53 private hosted zone associated with a VPC" +name = "AWS Route 53 Private Hosted Zone Associated With a VPC" note = """## Triage and analysis > **Disclaimer**: > This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. -### Investigating AWS Route53 private hosted zone associated with a VPC +### Investigating AWS Route 53 Private Hosted Zone Associated With a VPC -AWS Route53 private hosted zones allow for DNS management within a Virtual Private Cloud (VPC), ensuring internal resources are accessible only within the VPC. Adversaries might exploit this by associating unauthorized VPCs to intercept or reroute traffic. The detection rule identifies successful associations of VPCs with hosted zones, signaling potential misuse or unauthorized access attempts. +Route 53 private hosted zones provide internal DNS capabilities accessible only to the VPCs explicitly associated with +them. Associating a new VPC expands DNS visibility and access. If an adversary gains sufficient IAM permissions, they may +attach unauthorized VPCs to privileged hosted zones to perform internal reconnaissance, intercept service discovery, +redirect traffic, or gain persistence by manipulating internal name resolution. + +This rule detects successful `AssociateVPCWithHostedZone` events where a hosted zone's visibility scope is modified. ### Possible investigation steps -- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com to gather details about the AssociateVPCWithHostedZone action, including the time of the event and the identity of the user or role that performed the action. -- Verify the event.outcome:success to confirm that the association was successful and identify the specific VPC and hosted zone involved in the association. -- Check the AWS IAM policies and permissions of the user or role that initiated the association to ensure they have the appropriate level of access and determine if the action aligns with their expected responsibilities. -- Investigate the associated VPC to determine if it is authorized and expected to be linked with the private hosted zone. Look for any unusual or unauthorized VPCs that may indicate potential misuse. -- Review recent changes or activities in the AWS account to identify any other suspicious actions or patterns that could suggest a broader security incident or compromise. +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the association. Validate whether this identity is expected to manage Route 53 or VPC networking. + +- **Review Request Details** + - Examine `aws.cloudtrail.request_parameters` to confirm which hosted zone and VPC were associated. Determine if the hosted zone contains sensitive internal service records, privileged DNS, or identity service endpoints. + +- **Validate the VPC** + - Identify whether the associated VPC belongs to an authorized environment (e.g., known production, staging, or internal networks). Check for unusual VPC creation events, cross-account VPC behavior, or recently observed anomalous resource provisioning. + +- **Assess Source Context** + - Inspect `source.ip` and `user_agent.original` for geographic anomalies, automation patterns, or suspicious tooling. + - Look for correlations with unusual IAM activity, privilege escalations, or policy modifications. + +- **Correlate With Broader Activity** + - Search for additional changes involving the same identity, including: + - Route 53 hosted zone modifications + - VPC peering creation + - Network ACL or security group changes + - IAM privilege modifications + - Identify whether this association is part of a larger sequence suggesting lateral movement or internal reconnaissance. + +- **Engage Relevant Teams** + - If initiated by a user, confirm intent with networking or cloud infrastructure teams. Validate whether the association aligns with deployment, migration, or environment expansion activities. ### False positive analysis -- Routine infrastructure changes may trigger this rule when legitimate VPCs are associated with private hosted zones during regular operations. To manage this, maintain an updated list of authorized VPCs and compare them against the detected associations. -- Automated deployment tools or scripts that frequently associate VPCs with hosted zones can cause false positives. Identify these tools and create exceptions for their known activities to reduce noise. -- Development and testing environments often involve frequent changes and associations of VPCs with hosted zones. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. -- Scheduled maintenance or updates might involve temporary associations of VPCs with hosted zones. Document these schedules and incorporate them into the monitoring system to prevent false alerts during these periods. +- **Routine Infrastructure Updates** + - Associations may occur during normal environment expansions (new VPC for microservices, deployments, region expansion). + +- **Automated Tooling** + - Infrastructure-as-code pipelines (Terraform, CloudFormation, CDK) may regularly modify hosted zone associations. + - If confirmed legitimate, consider excluding specific automation IAM roles. + +- **Migration or Restructuring Events** + - Large-scale cloud migrations or VPC re-architecture work may trigger frequent legitimate associations. ### Response and remediation -- Immediately isolate the VPC associated with the unauthorized Route53 private hosted zone to prevent further unauthorized access or data exfiltration. -- Review CloudTrail logs to identify the source and method of the unauthorized VPC association, focusing on the user or role that performed the action. -- Revoke any unauthorized access or permissions identified during the log review, particularly those related to the IAM roles or users involved in the incident. -- Conduct a security review of the affected VPC and associated resources to ensure no other configurations have been tampered with or compromised. -- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. -- Implement additional monitoring and alerting for similar events in the future, ensuring that any unauthorized associations are detected promptly. -- Review and update IAM policies and security group rules to enforce the principle of least privilege, reducing the risk of similar incidents occurring. +- **Revoke Unauthorized Access** + - If the association is unauthorized, review and restrict IAM permissions for the actor. + - Remove the VPC association if it is not intended. + +- **Investigate Potential Impact** + - Review internal DNS query logs and VPC flow logs for any misuse, suspicious lookups, or unauthorized cross-VPC traffic. + +- **Strengthen IAM Controls** + - Limit `route53:AssociateVPCWithHostedZone` to specific administrative roles. + - Require MFA for accounts with Route 53 and VPC modification permissions. -## Setup +- **Monitor for Related Activity** + - Add monitoring for other hosted zone modifications, new VPC creation, and cross-account network configurations. -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +- **Communicate and Document** + - Notify cloud networking and security operations of unauthorized changes. + - Document findings and update policy controls or automation baselines. + +### Additional information +- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** +- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** +- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)** +""" references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"] -risk_score = 21 +risk_score = 47 rule_id = "e3c27562-709a-42bd-82f2-3ed926cced19" -severity = "low" +severity = "medium" tags = [ "Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", - "Data Source: AWS Route53", + "Data Source: AWS Route 53", "Use Case: Asset Visibility", "Tactic: Persistence", + "Tactic: Resource Development", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "query" query = ''' -event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com and event.action:AssociateVPCWithHostedZone and -event.outcome:success +event.dataset: aws.cloudtrail + and event.provider: route53.amazonaws.com + and event.action: AssociateVPCWithHostedZone + and event.outcome: success ''' @@ -91,4 +138,38 @@ reference = "https://attack.mitre.org/techniques/T1098/" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1583" +name = "Acquire Infrastructure" +reference = "https://attack.mitre.org/techniques/T1583/" +[[rule.threat.technique.subtechnique]] +id = "T1583.001" +name = "Domains" +reference = "https://attack.mitre.org/techniques/T1583/001/" + + + +[rule.threat.tactic] +id = "TA0042" +name = "Resource Development" +reference = "https://attack.mitre.org/tactics/TA0042/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +]