AWS Route 53 Domain Transferred to Another Account

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2021/05/10"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/12/10"
  6
  7[rule]
  8author = ["Elastic", "Austin Songer"]
  9description = """
 10Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes
 11administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic,
 12request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users
 13or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or
 14stage infrastructure for broader attacks. This rule detects successful domain transfer requests.
 15"""
 16false_positives = [
 17    """
 18    Internal account restructuring, mergers and acquisitions, or legitimate ownership transfers between business units
 19    may involve transferring DNS domains to other AWS accounts. Confirm the transfer is approved and documented in
 20    change management processes before taking action. Transfers performed by unfamiliar identities, originating from
 21    atypical locations, or outside expected maintenance windows should be investigated.
 22    """,
 23]
 24from = "now-6m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS Route 53 Domain Transferred to Another Account"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating AWS Route 53 Domain Transferred to Another Account
 35
 36Transferring a Route 53 domain to another AWS account is a high-impact administrative action. A successful transfer enables the
 37recipient account to fully manage the domain and all associated DNS resources. Unauthorized transfers can result in loss of
 38visibility and control, traffic redirection, service outages, or domain hijacking for phishing, credential harvesting, or command-and-control.
 39
 40This rule detects successful calls to `TransferDomainToAnotherAwsAccount`. These events are rare and should be considered
 41high-risk unless explicitly documented and approved.
 42
 43### Possible investigation steps
 44
 45- **Identify the actor and authentication context**
 46  - 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.
 47
 48- **Review request details and target account**
 49  - 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.
 50
 51- **Assess environment and timing**
 52  - 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.
 53
 54- **Analyze source and execution context**
 55  - Review `source.ip`, `source.geo.country_iso_code`, and `user_agent.original` to determine:
 56    - 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.
 57
 58- **Correlate with broader activity**
 59  - Pivot on the same IAM principal or access key ID to identify:
 60    - Recent IAM policy changes or privilege escalation
 61    - `DisableDomainTransferLock`, which normally precedes domain transfers
 62    - AWS console sign-ins from new geolocations or ASNs
 63    - API calls involving certificate requests, hosted zone changes, or DNS record edits
 64  - Look for evidence of lateral movement or credential theft preceding the transfer.
 65
 66- **Validate with business owners**
 67  - Confirm with domain owners, development teams, or asset managers whether The transfer was intentional.
 68
 69### False positive analysis
 70
 71- **Expected domain migrations**
 72  - Organizations with multi-account strategies may transfer domains between operational, security, or sandbox accounts.
 73- **Business events**
 74  - Mergers, acquisitions, or contractual transitions between managed service providers often involve bulk domain transfers.
 75- **Automated administrative tooling**
 76  - Domain lifecycle automation or infrastructure-as-code pipelines may trigger transfers if misconfigured.
 77  
 78### Response and remediation
 79
 80- **Contain and revoke access**
 81  - If unauthorized, immediately invalidate the IAM session or access keys used in the transfer.
 82  - Rotate credentials for the implicated IAM user or role and require MFA for privileged operations.
 83
 84- **Reverse or halt the transfer**
 85  - Contact AWS Support as soon as possible to request assistance reversing or blocking the transfer if it was not approved.
 86  - Re-enable transfer lock (`DisableDomainTransferLock=false`) to prevent further modifications.
 87
 88- **Investigate the extent of compromise**
 89  - Review CloudTrail to identify all actions performed by the actor before and after the transfer.
 90  - Check for additional changes to hosted zones, DNS records, certificates, or registrar contact details.
 91
 92- **Restore operational integrity**
 93  - Validate DNS routing, certificate issuance, and application endpoints for signs of redirection or tampering.
 94  - Communicate with impacted teams and external stakeholders if customer-facing domains were affected.
 95
 96- **Hardening and long-term improvements**
 97  - Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as `aws:PrincipalArn` and `aws:MultiFactorAuthPresent`
 98  - Consider SCPs to block domain-transfer APIs in production accounts.
 99  - Add change-management tracking for domain ownership modifications.
100
101### Additional information
102- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
103- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
104- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
105"""
106references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"]
107risk_score = 73
108rule_id = "2045567e-b0af-444a-8c0b-0b6e2dae9e13"
109severity = "high"
110tags = [
111    "Domain: Cloud",
112    "Data Source: AWS",
113    "Data Source: Amazon Web Services",
114    "Data Source: AWS Route 53",
115    "Use Case: Asset Visibility",
116    "Tactic: Persistence",
117    "Tactic: Resource Development",
118    "Resources: Investigation Guide",
119]
120timestamp_override = "event.ingested"
121type = "query"
122
123query = '''
124event.dataset: aws.cloudtrail 
125    and event.provider: route53domains.amazonaws.com 
126    and event.action: TransferDomainToAnotherAwsAccount 
127    and event.outcome: success
128'''
129
130
131[[rule.threat]]
132framework = "MITRE ATT&CK"
133[[rule.threat.technique]]
134id = "T1098"
135name = "Account Manipulation"
136reference = "https://attack.mitre.org/techniques/T1098/"
137
138
139[rule.threat.tactic]
140id = "TA0003"
141name = "Persistence"
142reference = "https://attack.mitre.org/tactics/TA0003/"
143[[rule.threat]]
144framework = "MITRE ATT&CK"
145[[rule.threat.technique]]
146id = "T1584"
147name = "Compromise Infrastructure"
148reference = "https://attack.mitre.org/techniques/T1584/"
149[[rule.threat.technique.subtechnique]]
150id = "T1584.001"
151name = "Domains"
152reference = "https://attack.mitre.org/techniques/T1584/001/"
153
154
155
156[rule.threat.tactic]
157id = "TA0042"
158name = "Resource Development"
159reference = "https://attack.mitre.org/tactics/TA0042/"
160
161[rule.investigation_fields]
162field_names = [
163    "@timestamp",
164    "user.name",
165    "user_agent.original",
166    "source.ip",
167    "aws.cloudtrail.user_identity.arn",
168    "aws.cloudtrail.user_identity.type",
169    "aws.cloudtrail.user_identity.access_key_id",
170    "target.entity.id",
171    "event.action",
172    "event.outcome",
173    "cloud.account.id",
174    "cloud.region",
175    "aws.cloudtrail.request_parameters",
176    "aws.cloudtrail.response_elements",
177]

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 Domain Transferred to Another Account

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

  • 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.
  • 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.
  • 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

  • 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.
  • 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.
  • 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

References

Related rules

to-top