nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/aws/persistence_ec2_route_table_modified_or_deleted.toml

@@ -0,0 +1,151 @@
+[metadata]
+creation_date = "2021/06/05"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/09/04"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Identifies AWS CloudTrail events where an EC2 route table or association has been modified or deleted. Route table or
+association modifications can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role.
+"""
+false_positives = [
+    """
+    Route Tables could be modified or deleted by a system administrator. Verify whether the user identity, user agent,
+    and/or hostname should be making changes in your environment. Route Tables being modified from unfamiliar users
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule. Also
+    automated processes that use Terraform may lead to false positives.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS EC2 Route Table Modified or Deleted"
+note = """
+## Triage and Analysis
+
+### Investigating AWS EC2 Route Table Modified or Deleted
+
+This rule detects modifications or deletions of AWS route tables using actions such as `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`. These actions may indicate legitimate administrative activity, but they can also be abused by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment.
+
+#### Possible Investigation Steps
+
+- **Review Request Parameters:**
+   - Check the `aws.cloudtrail.request_parameters` field. The sub-fields may vary depending on the `event.action` (e.g., `routeTableId` for `DeleteRouteTable`, `destinationCidrBlock` for `ReplaceRoute`).
+   - Validate the affected route table, routes, or associations based on the API call:
+     - For `ReplaceRoute`: Look for changes in specific routes using `destinationCidrBlock`.
+     - For `ReplaceRouteTableAssociation`: Review the new association details (e.g., subnet ID).
+     - For `DeleteRouteTable`: Confirm the `routeTableId` of the deleted table.
+     - For `DisassociateRouteTable`: Verify the disassociated resources.
+
+- **Review User Context**:
+  - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role initiating the action. Investigate whether this user is authorized to perform these operations.
+  - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify if the access key used was expected or potentially compromised.
+  - **Access Patterns**: Validate whether the user or role has a history of performing route table modifications and whether this aligns with their expected responsibilities.
+
+- **Analyze Request Details**:
+  - **Action Type**: Verify the specific API call in the `event.action` field (e.g., `ReplaceRoute`, `DeleteRouteTable`) to understand the nature of the modification.
+  - **Source IP and Geolocation**: Examine the `source.ip` and `source.geo` fields to confirm whether the request originated from a trusted location. Suspicious geolocations or IPs may indicate adversarial activity.
+  - **User Agent**: Review the `user_agent.original` field to determine the tool used for the request (e.g., AWS CLI, Terraform). Unusual or custom user agents may indicate malicious intent.
+
+- **Correlate with Other Activity**:
+  - **Concurrent API Calls**: Look for related API calls (e.g., `CreateRoute`, `AuthorizeSecurityGroupIngress`, or `ModifyInstanceAttribute`) from the same user or IP to detect broader attack patterns.
+  - **IAM Changes**: Investigate whether any IAM policy updates or privilege escalation attempts preceded this activity.
+  - **Unusual Volume of Changes**: Check if the user has performed multiple route table modifications or deletions in a short timeframe.
+
+- **Validate the Intent**:
+  - **Planned Changes**: Confirm with administrators whether the route table changes were part of a planned update or maintenance activity.
+  - **Permissions and Justification**: Ensure that the user or role has the least privilege necessary for these actions and that there is a valid reason for modifying the route table.
+
+### False Positive Analysis
+
+- **Routine Administration**: Route table modifications are often part of routine administrative tasks, such as creating new routes, updating associations, or removing unused resources.
+- **Automation Tools**: Automated workflows, such as those executed by Terraform or CloudFormation, may trigger these events. Verify whether the `user_agent.original` field or source IP matches known automation tools.
+- **Maintenance or Scaling**: Confirm whether these actions align with maintenance activities or scaling events (e.g., adding or removing subnets).
+
+### Response and Remediation
+
+- **Revoke Unauthorized Permissions**: If unauthorized, remove permissions for related actions from the user or role. You can use the managed [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) policy.
+- **Restore the Route Table**:
+  - If critical networking was impacted, restore the route table or reapply previous configurations from backups or Terraform state files.
+  - Verify connectivity to affected subnets or instances to ensure no disruptions to services.
+- **Audit IAM Policies**:
+  - Limit route table modification permissions to specific trusted users, roles, or automation accounts.
+  - Implement conditions in IAM policies, such as source IP restrictions, to reduce the risk of unauthorized access.
+- **Monitor and Alert**:
+  - Set up additional alerts for unexpected route table modifications or deletions.
+  - Use VPC flow logs and CloudTrail to monitor for related suspicious activity.
+- **Secure Automation**: Ensure automation tools, such as Terraform or CloudFormation, are configured securely and that their credentials are stored in secure locations like AWS Secrets Manager.
+"""
+references = [
+    "https://github.com/easttimor/aws-incident-response#network-routing",
+    "https://docs.datadoghq.com/security_platform/default_rules/aws-ec2-route-table-modified/",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRoute.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRouteTableAssociation",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRouteTable.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRoute.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateRouteTable.html",
+]
+risk_score = 21
+rule_id = "e7cd5982-17c8-4959-874c-633acde7d426"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EC2",
+    "Use Case: Network Security Monitoring",
+    "Resources: Investigation Guide",
+    "Tactic: Persistence",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "ec2.amazonaws.com"
+    and event.action:(
+        "ReplaceRoute" or
+        "ReplaceRouteTableAssociation" or
+        "DeleteRouteTable" or
+        "DeleteRoute" or
+        "DisassociateRouteTable"
+    )
+    and event.outcome: "success"
+'''
+
+[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"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["cloud.account.id", "user.name"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"
+
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml

@@ -0,0 +1,144 @@
+[metadata]
+creation_date = "2021/05/05"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/07/10"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment.
+"""
+false_positives = [
+    """
+    A security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS EC2 Security Group Configuration Change"
+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 EC2 Security Group Configuration Change
+
+This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
+
+#### Possible Investigation Steps
+
+1. **Identify the Modified Security Group**:
+   - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected.
+   - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.
+
+2. **Review User Context**:
+   - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.
+   - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.
+
+3. **Analyze the Configuration Change**:
+   - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.
+   - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.
+
+4. **Check User Agent and Source IP**:
+   - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.
+   - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.
+
+5. **Evaluate for Persistence Indicators**:
+   - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.
+   - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary.
+
+6. **Correlate with Other CloudTrail Events**:
+   - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.
+   - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.
+
+### False Positive Analysis
+
+- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.
+- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.
+
+### Response and Remediation
+
+- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.
+- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.
+- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.
+- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.
+
+### Additional Information
+
+For more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.
+"""
+references = ["https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html"]
+risk_score = 21
+rule_id = "29052c19-ff3e-42fd-8363-7be14d7c5469"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EC2",
+    "Use Case: Network Security Monitoring",
+    "Resources: Investigation Guide",
+    "Tactic: Persistence",
+    "Tactic: Defense Evasion"
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "ec2.amazonaws.com"  and event.outcome: "success"
+    and (event.action:(
+            "AuthorizeSecurityGroupIngress" or
+            "AuthorizeSecurityGroupEgress" or
+            "CreateSecurityGroup" or
+            "ModifySecurityGroupRules" or
+            "RevokeSecurityGroupEgress" or
+            "RevokeSecurityGroupIngress") or 
+            (event.action: "ModifyInstanceAttribute" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*))
+'''
+
+[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"
+]
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml

@@ -0,0 +1,173 @@
+[metadata]
+creation_date = "2025/04/16"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with
+"ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and
+are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM
+actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may
+indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials.
+"""
+false_positives = [
+    """
+    Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to
+    validate. Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert.
+    This can be verified in "event.original" as "sessionCredentialFromConsole: true"
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS IAM API Calls via Temporary Session Tokens"
+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 IAM API Calls via Temporary Session Tokens
+
+Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens 
+issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, 
+their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.
+
+Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. 
+They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to 
+establish persistence, escalate privileges, or disable protections.
+
+#### Possible investigation steps
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.
+  - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. 
+  - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse.
+
+- **Analyze the API context**
+  - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.
+  - Identify whether the action modifies roles, user policies, trust relationships, or credentials.
+  - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.
+
+- **Evaluate source and behavior**
+  - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.
+  - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.
+  - Compare `@timestamp` against normal operating hours or deployment schedules.
+
+- **Correlate related activity**
+  - Look for subsequent or preceding activity using the same access key:
+    - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)
+    - STS operations (`AssumeRole`, `GetCallerIdentity`)
+    - CloudTrail or GuardDuty configuration changes (possible defense evasion)
+  - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.
+
+### False positive analysis
+
+- **Expected automation**
+  - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.
+  - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.
+- **Administrative operations**
+  - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.
+  - Cross-reference with recent change tickets or known operations schedules.
+- **Federated identity scenarios**
+  - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity 
+    aligns with expected roles or groups.
+- **Console Login Session**
+  - Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true`
+
+### Response and remediation
+
+- **Containment**
+  - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.
+  - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.
+
+- **Investigation**
+  - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.
+  - Examine the creation of new users, keys, or policies during or shortly after the detected session.
+
+- **Recovery and hardening**
+  - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.
+  - Implement detection coverage for follow-on persistence actions such as:
+    - `iam:CreateAccessKey`
+    - `iam:PutUserPolicy`
+    - `iam:UpdateAssumeRolePolicy`
+  - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.
+
+### Additional information
+
+For more information on detecting and mitigating session token abuse:
+- **[AWS Security Token Service (STS) Documentation](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)**
+- **[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://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"]
+risk_score = 21
+rule_id = "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS CloudTrail",
+    "Data Source: AWS IAM",
+    "Data Source: AWS STS",
+    "Tactic: Persistence",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: aws.cloudtrail
+    and event.provider: ("iam.amazonaws.com")
+    and event.outcome: "success"
+    and aws.cloudtrail.user_identity.type: "IAMUser"
+    and aws.cloudtrail.user_identity.access_key_id: ASIA*
+    and source.ip: *
+    and not user_agent.original : "AWS Internal"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[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",
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["aws.cloudtrail.user_identity.arn"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml

@@ -0,0 +1,167 @@
+[metadata]
+creation_date = "2024/12/02"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner.
+
+"""
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS IAM Login Profile Added for Root"
+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.
+
+This rule detects when a console login profile is created for the AWS root account.  
+A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled.
+
+### Possible investigation steps
+
+**Assess the timing and context of the event**
+- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred.  
+  - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`.  
+  - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation.
+
+**Investigate event origin and session details**
+- Review `source.ip` and `user_agent.original`:
+  - Determine if the request originated from an expected network range, VPN endpoint, or geolocation.
+  - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client).
+- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used.
+- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts.
+
+**Analyze the login profile creation**
+- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`:
+  - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse.
+- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior.
+
+**Correlate related identity and access behavior**
+- Search for additional IAM management activity:
+  - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions.
+  - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session.
+- Review GuardDuty findings or any other detections referencing this account or IP around the same time period.
+- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition.
+
+**Validate with account owner or authorized personnel**
+- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery).
+- Review any internal change-management or service ticketing systems for an approved request matching this activity.
+
+### False positive analysis
+
+Although rare, legitimate scenarios include:
+- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows.  
+- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate.  
+- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials.
+
+For any potential false positive, verify that:
+- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools.  
+- The change was recorded during a maintenance window or known security operation.
+
+### Response and remediation
+
+> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation.
+
+**1. Containment**
+- Delete the newly created root login profile if it was not authorized.  
+- Rotate the root account password using AWS’s official password-reset workflow.  
+- Revoke any active sessions, temporary credentials, or tokens associated with this event.  
+- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account.  
+- Check that no root access keys exist — if present, remove them immediately.
+
+**2. Investigation and scoping**
+- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions.  
+- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity.  
+- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts.  
+- Review whether any new IAM roles, users, or policies were created in proximity to this event.
+
+**3. Recovery and hardening**
+- Reset the root password and distribute the new credentials securely to authorized custodians only.  
+- Ensure MFA is enforced for all administrative and root-level access.  
+- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions.  
+- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity.  
+- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed.
+
+**4. Post-incident actions**
+- Notify AWS account owners and your security operations center of the incident.  
+- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA).  
+- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR).
+
+### Additional information
+
+- **AWS Incident Response Playbooks**  
+  - [IRP-CredCompromise](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md) – Containment and recovery for suspected credential abuse.  
+- **AWS Customer Playbook Framework**  
+  - [Compromised_IAM_Credentials.md](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md) – Steps to contain, investigate, and recover from credential compromise.  
+- **AWS Documentation**  
+  - [CreateLoginProfile API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)  
+  - [Root User Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html)
+"""
+risk_score = 73
+rule_id = "c04be7e0-b0fc-11ef-a826-f661ea17fbce"
+severity = "high"
+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 = '''
+any where event.dataset == "aws.cloudtrail"
+   and event.provider == "iam.amazonaws.com"
+   and event.action == "CreateLoginProfile"
+   and aws.cloudtrail.user_identity.type == "Root"
+   and event.outcome == "success"
+   and not stringContains(aws.cloudtrail.request_parameters, "userName=")
+'''
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "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"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+