security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Rule Tunings] AWS IAM Roles Anywhere Rules (#5307)

Browse Source 
Both these rules are have low volume in telemetry as expected, this is quite rare behavior. No major changes to the rule logic itself.

AWS IAM Roles Anywhere Profile Creation
- updated description and investigation guide
- reduced execution window
- added highlighted fields

AWS IAM Roles Anywhere Trust Anchor Created with External CA
- changed rule type to EQL to use `stringContains` instead of leading wildcard
- uses `event.type` as event category override field
- reduced execution window
- updated description and investigation guide
- added highlighted fields
This commit is contained in:
Isai
2025-11-24 11:09:53 -05:00
committed by GitHub
parent 5188f22c7f
commit 52a17d8751
2 changed files with 195 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
+98 -32
View File
@@ -2,16 +2,16 @@
creation_date = "2024/04/20"
integration = ["aws"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/11/12"
[rule]
author = ["Elastic"]
description = """
Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is a feature that allows you to use AWS
Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted
anchors. This rule detects the creation of a profile that can be assumed from any service. Adversaries may create
profiles tied to overly permissive roles to maintain access to AWS resources. Ensure that the profile creation is
expected and that the trust policy is configured securely.
Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to
assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who
have established persistence through a rogue trust anchor may create or modify profiles to link them with highly
privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful
"CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations.
"""
false_positives = [
"""
@@ -19,47 +19,96 @@ false_positives = [
location. Ensure that the profile created is expected and that the trust policy is configured securely.
""",
]
from = "now-30m"
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Roles Anywhere Profile Creation"
note = """
## Triage and analysis
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, validate and adapt it to suit your operational needs.
### Investigating AWS IAM Roles Anywhere Profile Creation
This rule detects the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere allows you to use AWS Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted anchors. Adversaries may create profiles tied to overly permissive roles to maintain access to AWS resources. It is crucial to ensure that the profile creation is expected and that the trust policy is configured securely.
AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services —
to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that
can be assumed, the trust anchor they are associated with, and session duration limits.
#### Possible Investigation Steps:
This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile
creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with
unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles
and anchors are in use.
- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who created the profile. Verify if this actor typically performs such actions and if they have the necessary permissions.
- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the profile creation. Look for any unusual parameters or overly permissive roles that could suggest unauthorized or malicious activity.
- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the location and origin of the request. Ensure the request originated from a known and trusted location.
- **Check the Created Profile’s Permissions**: Review the `roleArns` associated with the created profile. Verify that the roles are appropriate for the user's intended actions and do not grant excessive permissions.
- **Verify the Profile’s Configuration**: Ensure that the profile's `durationSeconds`, `enabled`, and `tags` are configured according to your organization's security policies. Pay particular attention to any configuration that might allow prolonged access or concealment of activity.
#### Possible investigation steps
### False Positive Analysis:
- **Identify the actor**
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine
which IAM user, role, or principal created the profile.
- Check whether this identity normally manages Roles Anywhere configurations.
- **Legitimate Administrative Actions**: Confirm if the profile creation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the profile creation was successful and intended according to policy.
- **Review profile configuration**
- Inspect `aws.cloudtrail.request_parameters` for key values such as:
- `profileName`
- `roleArns` – confirm that the listed IAM roles are expected and not overly permissive.
- `trustAnchorArn` – verify the trust anchor is valid and authorized.
- `durationSeconds` – check for unusually long session durations.
- Determine if multiple roles were attached, which may indicate excessive privilege aggregation.
### Response and Remediation:
- **Correlate related activity**
- Check for prior or concurrent events by the same actor, including:
- `CreateTrustAnchor` with external or unauthorized certificate authorities.
- `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths.
- Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile.
- **Immediate Review and Reversal if Necessary**: If the profile creation was unauthorized, disable or delete the created profile and review the associated roles and permissions for any potential misuse.
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive roles or unexpected locations.
- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning profile and role management and the risks of unauthorized profile creation.
- **Audit IAM Policies and Permissions**: Conduct a comprehensive audit of all IAM policies and associated permissions to ensure they adhere to the principle of least privilege.
- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
- **Assess the source context**
- Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs).
- Compare to baseline patterns of legitimate IAM or infrastructure automation.
### Additional Information:
- **Validate legitimacy**
- Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation
aligns with approved change management or onboarding activities.
For further guidance on managing AWS IAM Roles Anywhere profiles and securing AWS environments, refer to the [AWS Roles Anywhere documentation](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) and AWS best practices for security. Additionally, consult the following resources for specific details on profile management and potential abuse:
- [AWS IAM Roles Anywhere Profile Creation API Reference](https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html)
- [Ermetic Blog - Managing Third Party Access](https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/)
### False positive analysis:
- **Legitimate administrative actions**
- IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads.
Validate against change control records and deployment logs.
- **Authorized automation**
- Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles.
Confirm these operations are sourced from known automation accounts or IP ranges.
- **Development and testing**
- Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls.
Ensure alerts from non-production accounts are tuned accordingly.
### Response and remediation:
- **Immediate review and containment**
- If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all
associated IAM roles for misuse.
- Rotate any credentials or revoke certificates issued from unapproved trust anchors.
- **Investigation**
- Search CloudTrail for additional related actions by the same identity, such as
`CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts.
- Verify whether any sessions have been initiated using the new profile and identify
which roles were assumed.
- **Recovery and hardening**
- Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles.
- Implement AWS Config or Security Hub controls to alert on unauthorized or overly
permissive Roles Anywhere profiles.
- Audit IAM role trust policies linked to external anchors and ensure adherence to the
principle of least privilege.
- Review and document all approved Roles Anywhere profiles and their corresponding trust anchors.
### 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",
@@ -83,7 +132,7 @@ timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail
event.dataset: aws.cloudtrail
and event.provider: rolesanywhere.amazonaws.com
and event.action: CreateProfile
and event.outcome: success
@@ -108,3 +157,20 @@ 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",
]
rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
+97 -39
View File
@@ -2,17 +2,19 @@
creation_date = "2024/04/20"
integration = ["aws"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/11/12"
[rule]
author = ["Elastic"]
description = """
Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles
Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This
rule detects when a trust anchor is created with an external certificate authority that is not managed by AWS
Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in
the environment.
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
@@ -20,47 +22,85 @@ false_positives = [
certificate authority is authorized.
""",
]
from = "now-30m"
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
language = "eql"
license = "Elastic License v2"
name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
note = """
## Triage and analysis
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, validate and adapt it to suit your operational needs.
### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA
This rule detects when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This rule identifies when a trust anchor is created with an external certificate authority that is not managed by AWS Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in the environment.
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.
#### Possible Investigation Steps:
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.
- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the trust anchor creation. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the trust anchor was created. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
- **Verify the Certificate Authority**: Ensure that the external certificate authority used is authorized and recognized. Unauthorized external CAs can be a red flag for malicious activity.
#### Possible investigation steps
### False Positive Analysis:
- **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.
- **Legitimate Administrative Actions**: Confirm if the trust anchor creation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the creation was successful and intended according to policy.
- **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.
### Response and Remediation:
- **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.
- **Immediate Review and Reversal if Necessary**: If the creation was unauthorized, remove the trust anchor and revoke any associated permissions.
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving the creation of trust anchors with external certificate authorities.
- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning IAM Roles Anywhere and the use of certificate authorities.
- **Audit IAM Roles and Policies**: Conduct a comprehensive audit of all IAM roles and associated policies to ensure they adhere to the principle of least privilege.
- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
- **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.
### Additional Information:
- **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.
For further guidance on managing IAM Roles Anywhere and securing AWS environments, refer to the [AWS IAM Roles Anywhere documentation](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) and AWS best practices for security. Additionally, consult the following resources for specific details on IAM roles and trust anchors:
- [AWS IAM Roles Anywhere Introduction](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
- [Ermetic Blog on IAM Users and Third Parties](https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/)
### 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",
@@ -80,14 +120,14 @@ tags = [
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
type = "eql"
query = '''
event.dataset: aws.cloudtrail
and event.provider: rolesanywhere.amazonaws.com
and event.action: CreateTrustAnchor
and event.outcome: success
and not aws.cloudtrail.request_parameters: *sourceType=AWS_ACM_PCA*
info where event.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")
'''
@@ -109,3 +149,21 @@ 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",
"target.entity.id",
"event.action",
"event.outcome",
"cloud.account.id",
"cloud.region",
"aws.cloudtrail.request_parameters",
"aws.cloudtrail.response_elements",
]