AWS IAM Roles Anywhere Trust Anchor Created with External CA

ELASTIC detection rule by Elastic · Elastic License v2

Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs.

[metadata]
creation_date = "2024/04/20"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather
than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential
issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a
trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from
any location, even after key rotation or credential revocation events. This rule helps detect persistence or
unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs.
"""
event_category_override = "event.type"
false_positives = [
    """
    AWS IAM Roles Anywhere Trust Anchors are legitimate profiles that can be created by administrators to allow access
    from any location. Ensure that the trust anchor is created by a legitimate administrator and that the external
    certificate authority is authorized.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
note = """## Triage and analysis

### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA

AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate 
these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance 
and revocation. 

This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA.

#### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
  - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup.

- **Review the trust anchor details**
  - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain.
  - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates.

- **Assess the scope and risk**
  - Identify which IAM roles are linked to this trust anchor via `Profile` associations.
  - Determine whether any of those roles provide privileged or cross-account access.
  - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether 
    the external CA has been used.

- **Correlate related activity**
  - Search for preceding reconnaissance or setup activity:
    - `ListTrustAnchors`, `ListProfiles`, `GetRole`
    - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`)
  - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications.

- **Validate legitimacy**
  - Confirm with identity management or security engineering teams whether the external CA is an approved authority.
  - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain.

### False positive analysis

- **Legitimate external CA use**
  - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem.
- **Testing and lab accounts**
  - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations.
  - Confirm that such activity occurs in isolated accounts and not in production.
- **Expected administrative setup**
  - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or 
    deployment logs before treating as suspicious.

### Response and remediation

- **Containment**
  - If the CA is unauthorized, immediately delete the trust anchor using 
    `aws rolesanywhere delete-trust-anchor --trust-anchor-id <id>`.
  - Review for any certificates already used to assume roles and revoke those certificates from the external CA.

- **Investigation**
  - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`).
  - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA.
  - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation.

- **Recovery and hardening**
  - Replace unauthorized CAs with ACM PCA-managed ones.
  - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only.
  - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings.
  - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior.

### 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)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html",
    "https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/",
    "https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateTrustAnchor.html",
]
risk_score = 47
rule_id = "71de53ea-ff3b-11ee-b572-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"
  and event.provider == "rolesanywhere.amazonaws.com"
  and event.action == "CreateTrustAnchor"
  and event.outcome == "success"
  and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[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",
]

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

437da221-7988-4be5-8ec5-2867a2dd4038

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion