AWS Route 53 Domain Transfer Lock Disabled

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2021/05/10"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/01/16"
  6
  7[rule]
  8author = ["Elastic", "Austin Songer"]
  9description = """
 10Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being
 11moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard
 12against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a
 13precursor to unauthorized domain transfer, takeover, or service disruption.
 14"""
 15false_positives = [
 16    """
 17    A domain transfer lock may be intentionally disabled by an authorized administrator to prepare for a planned domain
 18    migration or registrar change. Confirm that the action aligns with an approved change request. You may exempt known
 19    administrative accounts involved in routine domain operations to reduce noise.
 20    """,
 21]
 22from = "now-6m"
 23index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "AWS Route 53 Domain Transfer Lock Disabled"
 27note = """## Triage and analysis
 28
 29### Investigating AWS Route 53 Domain Transfer Lock Disabled
 30
 31This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock
 32prevents unauthorized domain transfers, and disabling it is an uncommon operation outside of planned migrations. Because
 33domains often underpin production workloads (web, API, authentication, email), unauthorized transfer lock changes may
 34indicate adversary preparation for domain hijacking or service disruption.
 35
 36This event should be treated with high urgency whenever it occurs unexpectedly.
 37
 38### Possible investigation steps
 39
 40- **Review the actor**
 41  - Examine `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to confirm who
 42    initiated the change. Validate whether this identity normally performs domain-management tasks.
 43
 44- **Analyze the request context**
 45  - Review `aws.cloudtrail.request_parameters` to identify which domain was affected.
 46  - Confirm no corresponding `operation=TransferDomainToAnotherAwsAccount` or registrar-level modifications occurred
 47    shortly before or after the lock was disabled.
 48  - Note the timestamp and evaluate whether the change occurred during maintenance windows or outside business hours.
 49
 50- **Evaluate activity surrounding the lock disablement**
 51  - 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.
 52
 53- **Validate intent with responsible teams**
 54  - Confirm whether stakeholders (network operations, domain owners, infrastructure leads) initiated or approved the
 55    transfer lock disablement. If unmanaged or unexpected, treat this as a potentially malicious action.
 56
 57### False positive analysis
 58
 59- **Authorized transfer preparation**
 60  - The most common legitimate case is preparation for a planned transfer of ownership or registrar migration. Ensure the
 61    change aligns with a ticketed and approved operation.
 62
 63- **Internal domain restructuring**
 64  - Organizational changes (e.g., merging AWS accounts, consolidating DNS assets) may require disabling the lock. Check
 65    for documented work items or migration plans.
 66
 67- **Automated tooling**
 68  - Rare but possible: Some internal automation used for domain lifecycle management may disable the lock as part of an
 69    update. Validate that any automation using administrative API credentials is documented and approved.
 70
 71### Response and remediation
 72
 73- **Re-enable the transfer lock immediately if unauthorized**
 74  - Restore the lock from Route 53 to prevent any pending or future unauthorized transfer attempts.
 75
 76- **Contain potential credential compromise**
 77  - If the action is suspicious, rotate credentials for the user or role involved and enforce MFA.
 78
 79- **Audit for related domain-level modifications**
 80  - Review CloudTrail logs for:
 81    - attempted domain transfers,
 82    - contact profile changes,
 83    - hosted zone modifications,
 84    - DNS record updates,
 85    - IAM privilege escalations.
 86
 87- **Engage internal owners**
 88  - Notify domain owners, infosec leadership, and operations teams; determine business impact and next steps.
 89
 90- **Strengthen governance**
 91  - Limit domain-management permissions to the minimum set of authorized administrators.
 92  - Consider implementing AWS Organizations service control policies (SCPs) to prevent domain-level actions except
 93    through designated accounts.
 94
 95### Additional information
 96- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
 97- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
 98- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
 99"""
100references = [
101    "https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html",
102    "https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_DisableDomainTransferLock.html",
103]
104risk_score = 73
105rule_id = "12051077-0124-4394-9522-8f4f4db1d674"
106severity = "high"
107tags = [
108    "Domain: Cloud",
109    "Data Source: AWS",
110    "Data Source: Amazon Web Services",
111    "Data Source: AWS Route 53",
112    "Use Case: Asset Visibility",
113    "Tactic: Persistence",
114    "Tactic: Resource Development",
115    "Resources: Investigation Guide",
116]
117timestamp_override = "event.ingested"
118type = "query"
119
120query = '''
121event.dataset: aws.cloudtrail 
122    and event.provider: route53domains.amazonaws.com 
123    and event.action: DisableDomainTransferLock 
124    and event.outcome: success
125'''
126
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130[[rule.threat.technique]]
131id = "T1098"
132name = "Account Manipulation"
133reference = "https://attack.mitre.org/techniques/T1098/"
134
135
136[rule.threat.tactic]
137id = "TA0003"
138name = "Persistence"
139reference = "https://attack.mitre.org/tactics/TA0003/"
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142[[rule.threat.technique]]
143id = "T1584"
144name = "Compromise Infrastructure"
145reference = "https://attack.mitre.org/techniques/T1584/"
146[[rule.threat.technique.subtechnique]]
147id = "T1584.001"
148name = "Domains"
149reference = "https://attack.mitre.org/techniques/T1584/001/"
150
151
152
153[rule.threat.tactic]
154id = "TA0042"
155name = "Resource Development"
156reference = "https://attack.mitre.org/tactics/TA0042/"
157
158[rule.investigation_fields]
159field_names = [
160    "@timestamp",
161    "user.name",
162    "user_agent.original",
163    "source.ip",
164    "aws.cloudtrail.user_identity.arn",
165    "aws.cloudtrail.user_identity.type",
166    "aws.cloudtrail.user_identity.access_key_id",
167    "event.action",
168    "event.outcome",
169    "cloud.account.id",
170    "cloud.region",
171    "aws.cloudtrail.request_parameters",
172    "aws.cloudtrail.response_elements",
173]

Triage and analysis

Investigating AWS Route 53 Domain Transfer Lock Disabled

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

  • 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

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

References

Related rules

to-top