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

nldcsc_elastic_rules/rules/integrations/aws/persistence_rds_instance_made_public.toml

@@ -2,16 +2,21 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the creation or modification of an AWS RDS DB instance to enable public access. DB instances may contain sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may enable public access on a DB instance to maintain persistence or evade defenses by bypassing access controls.
+Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute
+is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow
+unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM
+policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to
+establish persistence, move data outside of controlled network boundaries, or bypass internal access controls.
 """
 false_positives = [
     """
-    Public access is a common configuration used to enable access from outside a private VPC. Ensure that the instance should not be modified in this way before taking action.
+    Public access is a common configuration used to enable access from outside a private VPC. Ensure that the instance
+    should not be modified in this way before taking action.
     """,
 ]
 from = "now-6m"
@@ -19,39 +24,93 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Made Public"
-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 RDS DB Instance Made Public
 
-This rule identifies when an RDS DB instance is created or modified to enable public access. While publicly accessible DB instances are a common practice, adversaries may exploit this feature to maintain persistence or evade defenses in a compromised environment.
+This rule detects when an Amazon RDS DB instance or cluster is created or modified with
+`publiclyAccessible=true`. While some environments operate publicly accessible RDS instances,
+unexpected exposure of a database to the internet is a meaningful security risk. Adversaries who
+gain access to AWS credentials may modify a DB instance’s public accessibility to exfiltrate data,
+establish persistence, or bypass internal network restrictions. 
 
 #### Possible Investigation Steps
 
-- **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 Creation/Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance`, `CreateDBInstance` or `CreateDBCluster` actions where the publiclyAccessible parameter was set to true.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB Instance Identifier and any other modifications made to the instance.
-- **Verify the Created/Modified Instance**: Check the DB instance that was created or modified and its contents to determine the sensitivity of the data stored within it.
-- **Contextualize with Recent Changes**: Compare this event against recent changes in RDS DB or Cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this event to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Interview Relevant Personnel**: If the modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change.
+  - Determine whether the user, role, or automation service typically manages RDS configurations.
+
+- **Examine the request parameters**
+  - Review `aws.cloudtrail.request_parameters` for:
+    - `publiclyAccessible=true`
+    - DBInstanceIdentifier / DBClusterIdentifier
+    - Additional changes included in the same modification request (e.g., master user changes, security group updates)
+
+- **Validate the target resource**
+  - Determine the sensitivity of the instance (`target.entity.id`):
+    - What data does it store?
+    - Is it production, staging, dev, or ephemeral?
+  - Confirm whether the instance was previously private.
+
+- **Assess network exposure**
+  - Check associated security groups for:
+    - `0.0.0.0/0` (unrestricted ingress)
+    - Unexpected IP ranges  
+  - Review VPC/subnet placement to determine if the instance is reachable externally.
+
+- **Correlate with other recent CloudTrail activity**
+  - Look for related events performed by the same actor:
+    - `AuthorizeSecurityGroupIngress`
+    - `ModifyDBInstance`
+    - IAM policy modifications enabling broader DB access
+  - Look for indicators of credential misuse:
+    - unusual `source.ip`
+    - unusual `user_agent.original`
+    - MFA not used (`session_context.mfa_authenticated=false`)
+
+- **Validate intent with owners**
+  - Contact the service or database owner to confirm whether the change was an approved part of a deployment or migration.
+
 ### False Positive Analysis
 
-- **Legitimate Instance Configuration**: Confirm if the DB instance creation or modification aligns with legitimate tasks.
-- **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.
+- **Expected public-access configuration**
+  - Some workloads intentionally require public access (e.g., internet-facing reporting tools).
+  - Validate against change management tickets, deployment pipelines, or Terraform/IaC automation logs.
 
 ### Response and Remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
-- **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+- **Containment**
+  - If exposure is unauthorized:
+    - Modify the instance to disable public access (`publiclyAccessible=false`).
+    - Restrict the security group inbound rules immediately.
+    - Snapshot the instance to preserve state if compromise is suspected.
+
+- **Investigation**
+  - Review all recent actions from the same IAM principal.
+  - Check for data access patterns (CloudWatch, RDS Enhanced Monitoring, VPC Flow Logs).
+  - Identify whether this exposure correlates with suspicious outbound network activity.
+
+- **Hardening**
+  - Require private-only RDS instances unless explicitly documented.
+  - Enforce security group least privilege and block public DB access via:
+    - AWS Config rules (`rds-instance-public-access-check`)
+    - Service Control Policies (SCPs) preventing public RDS settings
+  - Implement continuous monitoring for network or configuration drift.
+
+- **Recovery**
+  - Restore the database to a private subnet if necessary.
+  - Rotate credentials used by the DB instance and associated applications.
+  - Document the incident and update policies or IaC templates to prevent recurrence.
 
 ### Additional Information:
 
-For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
-- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.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://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
@@ -86,6 +145,7 @@ any where event.dataset == "aws.cloudtrail"
     )
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -97,6 +157,8 @@ id = "T1556.009"
 name = "Conditional Access Policies"
 reference = "https://attack.mitre.org/techniques/T1556/009/"
 
+
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
@@ -108,3 +170,22 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[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",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_redshift_instance_creation.toml

@@ -2,7 +2,7 @@
 creation_date = "2022/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/25"
 
 [rule]
 author = ["Elastic"]
@@ -23,13 +23,13 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
-name = "AWS Redshift Cluster Creation"
+name = "Deprecated - AWS Redshift Cluster Creation"
 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 Redshift Cluster Creation
+### Investigating Deprecated - AWS Redshift Cluster Creation
 
 Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. In a secure environment, only authorized users should create Redshift clusters. Adversaries might exploit misconfigured permissions to create clusters, potentially leading to data exfiltration or unauthorized data processing. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations.
 

nldcsc_elastic_rules/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml

@@ -2,24 +2,23 @@
 creation_date = "2024/11/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/12/02"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when the STS `AssumeRoot` action is performed by a rare user in AWS. The AssumeRoot action allows users to
+Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to
 assume the root member account role, granting elevated but specific permissions based on the task policy specified.
-Adversaries whom may have compromised user credentials, such as access and secret keys, can use this technique to
-escalate privileges and gain unauthorized access to AWS resources. This is a [New
-Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies
-when the STS `AssumeRoot` action is performed by a user that rarely assumes this role and specific member account.
+Adversaries who have compromised user credentials can use this technique to
+escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies
+when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account.
 """
 false_positives = [
     "AWS administrators or automated processes might regularly assume root for legitimate administrative purposes.",
     "AWS services might assume root to access AWS resources as part of their standard operations.",
     "Automated workflows might assume root to perform periodic administrative tasks.",
 ]
-from = "now-9m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
@@ -27,66 +26,123 @@ name = "AWS STS AssumeRoot by Rare User and Member Account"
 note = """
 ## Triage and analysis
 
-### Investigating AWS STS AssumeRoot by Rare User and Member Account
-
-This rule identifies instances where AWS STS (Security Token Service) is used to assume a root role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.
-
-#### Possible Investigation Steps
-
-- **Identify the Actor and Assumed Role**:
-  - **User Identity**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` fields to determine who initiated the `AssumeRoot` action.
-  - **Account Context**: Check the `aws.cloudtrail.recipient_account_id` field for the account affected by the action. This is likely the management account.
-  - **Authentication**: If available, review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used for the action. This key may be compromised in the case of unauthorized activity.
-  - **Resources**: Inspect `aws.cloudtrail.resources.type` and `aws.cloudtrail.resources.arn` to determine the resource or role assumed. This is the member account where the root role was assumed.
-
-- **Analyze Request Parameters**:
-  - **Session Details**: Check `aws.cloudtrail.flattened.request_parameters.durationSeconds` for session duration.
-  - **Permissions**: Review `aws.cloudtrail.flattened.request_parameters.taskPolicyArn` for the associated policy. These policies are predefined and grant specific permissions to the assumed root account.
-  - **Target Entity**: Inspect the `aws.cloudtrail.flattened.request_parameters.targetPrincipal` field for the entity being accessed. This is typically the member account.
-  - **Target Policy**: Inspect the `aws.cloudtrail.flattened.request_parameters.targetPolicyArn` field for the policy applied to temporary root credentials. This can help determine the scope of the permissions granted.
-
-- **Examine Response Details**:
-  - **Credentials Issued**: Review `aws.cloudtrail.flattened.response_elements.credentials` to confirm credentials were issued and note their expiration (`expiration` field). The temporary access key can be used to pivot into other actions done by the assumed root account by searching for the value in `aws.cloudtrail.user_identity.access_key_id`.
-
-- **Inspect Source Details**:
-  - **Source IP and Location**: Evaluate `source.address` and `source.geo` fields to confirm the request's origin. Unusual locations might indicate unauthorized activity.
-  - **User Agent**: Analyze `user_agent.original` to determine the tool or application used (e.g., AWS CLI, SDK, or custom tooling).
-
-- **Correlate with Related Events**:
-  - **Concurrent Events**: Look for surrounding CloudTrail events that indicate follow-up actions, such as access to sensitive resources or privilege escalation attempts.
-  - **Historical Activity**: Review historical activity for the `aws.cloudtrail.user_identity.arn` to determine if this action is anomalous.
+> **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.
 
-- **Evaluate Privilege Escalation Risk**:
-  - **Role Privileges**: Inspect the privileges granted by the assumed role or task policy (`aws.cloudtrail.flattened.request_parameters.taskPolicyArn`).
-  - **Operational Context**: Confirm whether the action aligns with routine operations or is unusual.
-
-### False Positive Analysis
-
-- **Authorized Administrative Activity**:
-  - Verify if the activity was initiated by an AWS administrator for legitimate purposes.
-- **Automated Workflows**:
-  - Identify if the action was part of an automated process or workflow.
-
-### Response and Remediation
-
-1. **Revoke Unauthorized Credentials**:
-   - If malicious activity is identified, immediately revoke the session tokens and access keys associated with the `AssumeRoot` action.
-   - It may be worth removing the compromised access key from the affected user or service account.
-2. **Enhance Monitoring**:
-   - Increase the monitoring frequency for sensitive roles and actions, especially `AssumeRoot`.
-3. **Review IAM Policies**:
-   - Limit permissions for accounts or roles to assume root and enforce multi-factor authentication (MFA) where applicable.
-4. **Contain and Investigate**:
-   - Isolate affected accounts or roles and follow incident response procedures to determine the scope and impact of the activity.
-
-### Additional Information
+### Investigating AWS STS AssumeRoot by Rare User and Member Account
 
-For more information on AssumeRoot, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html).
+AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the
+task policy and target policy attached to the request. In normal operations, only a small set of platform, security, or
+automation roles should ever need to perform `AssumeRoot`, and typically only against a predictable set of member
+accounts.
+
+This rule is a New Terms rule that detects when a previously unseen combination of calling principal (`aws.cloudtrail.user_identity.arn`) and target member account (`aws.cloudtrail.resources.account_id`) successfully invokes `AssumeRoot`. Activity that matches this pattern may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows.
+
+#### Possible investigation steps
+
+- **Identify the actor and target context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine:
+    - Whether the caller is an IAM user, federated user, or role.
+    - Whether this identity is normally used for organization-level administration or automation.
+  - Inspect `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to identify the affected member account.
+  - Check `source.address`, `source.geo.*`, and `user_agent.original` to understand where and how the call was made (console, CLI, SDK, automation runner, VPN, corporate IP, etc.).
+
+- **Understand session, policy, and target details**
+  - Examine `aws.cloudtrail.request_parameters` for:
+    - `taskPolicyArn` – which predefined task policy was requested and what category of operations it enables (e.g., investigation, remediation, read-only, or broad admin).
+    - `targetPrincipal` and/or related target fields – which member account principal is being accessed.
+    - Any duration or configuration parameters (such as `durationSeconds`) that indicate unusually long-lived sessions.
+  - In `aws.cloudtrail.response_elements`, review:
+    - `credentials.accessKeyId` and `credentials.expiration` to confirm that credentials were successfully issued and how long they are valid.
+    - Any additional response fields that indicate session constraints or failures (if present).
+
+- **Correlate follow-on activity from the assumed root session**
+  - Use the temporary access key from `aws.cloudtrail.response_elements.credentials.accessKeyId` to pivot in CloudTrail:
+    - Search for subsequent events where `aws.cloudtrail.user_identity.access_key_id` matches that key.
+    - Look for high-impact actions such as:
+      - IAM changes (`iam:CreateUser`, `iam:AttachRolePolicy`, `iam:PutRolePolicy`, `iam:UpdateAssumeRolePolicy`).
+      - Guardrail changes (CloudTrail, Security Hub, Config, GuardDuty configuration or detector changes).
+      - Data-impacting actions (S3 bucket policy changes, RDS/RDS snapshot operations, EFS/RDS delete, secrets reads).
+  - Correlate with any prior events for the calling identity:
+    - STS calls that created the session used to invoke `AssumeRoot` (e.g., `AssumeRole`, SSO/identity provider activity).
+    - Recent IAM policy updates that broadened its ability to perform cross-account administration.
+
+- **Assess timing and operational alignment**
+  - Use `@timestamp`, `cloud.region`, and your change calendar to determine:
+    - Whether the event occurred during a documented maintenance window or deployment.
+    - Whether the region and account align with the caller’s normal operational scope.
+  - Compare with other events in the same time window:
+    - Organization-level changes, new account creation, or migration work.
+    - Other sensitive operations from the same `source.ip` or principal.
+
+- **Validate with owners**
+  - Confirm with:
+    - Cloud/infra platform teams that normally operate organization-level admin roles.
+    - Security/IR teams if they were running an investigation workflow that legitimately uses `AssumeRoot`.
+  - Check whether the use of `AssumeRoot` is documented in CI/CD or automation designs that might have just expanded to this account, explaining the New Terms trigger.
+
+### False positive analysis
+
+- **Legitimate administrative cross-account access**
+  - Platform, security, or central operations teams may use `AssumeRoot` as part of sanctioned workflows for:
+    - New account onboarding.
+    - Centralized remediation or investigation.
+    - Complex deployment or migration tasks.
+  - If this is the first time a specific engineer or automation role is onboarded to a given member account, the rule will fire once because it is a New Terms rule. Validate and, if appropriate, document this as expected behavior.
+
+- **Automation and scheduled workflows**
+  - CI/CD pipelines, organization-wide maintenance jobs, or incident response automation may use `AssumeRoot`:
+    - Identify automation roles and service principals that legitimately call `AssumeRoot`.
+    - Tune with rule exceptions based on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or specific `taskPolicyArn` values used only by trusted workflows.
+
+If a pattern emerges where specific roles regularly and legitimately assume root into a consistent set of accounts, consider documenting those identities and, if appropriate, creating narrow exceptions — while preserving coverage for new, unexpected combinations.
+
+### Response and remediation
+
+- **Contain potentially unauthorized sessions**
+  - If the activity appears suspicious or unapproved:
+    - Invalidate the credentials issued by `AssumeRoot` (where supported) or constrain their impact by immediately tightening IAM, SCPs, or network controls in the affected member account.
+    - Rotate or revoke long-lived access keys associated with the calling principal.
+    - Temporarily restrict permissions on roles allowed to call `AssumeRoot` until the investigation is complete.
+
+- **Investigate scope and impact**
+  - Using CloudTrail:
+    - Enumerate all actions performed with the `AssumeRoot` session access key and identify:
+      - Privilege changes (IAM users, roles, policies, permission boundaries, SCPs).
+      - Changes to logging and security controls (CloudTrail, GuardDuty, Security Hub, Config, firewall/WAF rules).
+      - Data-impacting operations on high-value services (S3, RDS, DynamoDB, Secrets Manager, KMS).
+    - Check if similar `AssumeRoot` activity has occurred recently from the same `source.ip`, principal, or member account.
+  - Engage application, data, and platform owners for the impacted account(s) to:
+    - Assess potential data exposure, integrity issues, or downtime.
+    - Determine whether any actions conflict with intended change plans.
+
+- **Hardening and preventive controls**
+  - Restrict and monitor `AssumeRoot` usage:
+    - Limit which IAM roles and identities can call `sts:AssumeRoot`, using IAM conditions (e.g., `aws:PrincipalArn`, `aws:PrincipalOrgID`, `aws:RequestedRegion`).
+    - Where possible, require strong authentication on the initiating principal (MFA, federated SSO, device posture).
+  - Add guardrails and observability:
+    - Use AWS Config, Security Hub, and/or AWS Organizations SCPs to:
+      - Detect or constrain highly privileged cross-account actions.
+      - Ensure logging and monitoring services cannot be disabled or modified by assumed sessions without additional friction.
+    - Ensure `AssumeRoot` activity is included in your SIEM dashboards and investigation playbooks.
+
+- **Post-incident improvements**
+  - If activity is confirmed malicious or unsafe:
+    - Rotate credentials for all involved principals and review recent STS session usage for anomalies.
+    - Update internal runbooks to clearly define when `AssumeRoot` is allowed, who can perform it, and how it should be documented.
+    - Refine this rule’s exceptions or tagging strategy so that legitimate, recurring workflows are well-understood, while preserving high-fidelity visibility into new or unexpected `AssumeRoot` 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/STS/latest/APIReference/API_AssumeRoot.html"]
-risk_score = 21
+risk_score = 47
 rule_id = "962a71ae-aac9-11ef-9348-f661ea17fbce"
-severity = "low"
+severity = "medium"
 tags = [
     "Domain: Cloud",
     "Data Source: AWS",
@@ -145,19 +201,20 @@ reference = "https://attack.mitre.org/tactics/TA0003/"
 [rule.investigation_fields]
 field_names = [
     "@timestamp",
-    "aws.cloudtrail.user_identity.type",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
     "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
     "aws.cloudtrail.user_identity.access_key_id",
-    "source.address",
     "aws.cloudtrail.resources.account_id",
-    "aws.cloudtrail.recipient_account_id",
-    "aws.cloudtrail.flattened.request_parameters",
+    "aws.cloudtrail.resources.type",
     "event.action",
     "event.outcome",
-    "aws.cloudtrail.flattened.request_parameters.taskPolicyArn",
+    "cloud.account.id",
     "cloud.region",
     "aws.cloudtrail.request_parameters",
-    "aws.cloudtrail.response_elements",
+    "aws.cloudtrail.response_elements"
 ]
 
 [rule.new_terms]
@@ -165,6 +222,6 @@ field = "new_terms_fields"
 value = ["aws.cloudtrail.user_identity.arn", "aws.cloudtrail.resources.account_id"]
 [[rule.new_terms.history_window_start]]
 field = "history_window_start"
-value = "now-10d"
+value = "now-7d"
 
 

nldcsc_elastic_rules/rules/integrations/azure/credential_access_azure_entra_susp_device_code_signin.toml

@@ -0,0 +1,134 @@
+[metadata]
+creation_date = "2025/12/02"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/12/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies concurrent Entra ID sign-in events for the same user and session from multiple sources, and where one of the
+authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may
+steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to
+Azure resources.
+"""
+false_positives = [
+    """
+    Users authenticating from multiple devices and using the deviceCode protocol or the Visual Studio Code client.
+    """,
+]
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Suspicious Microsoft Entra ID Concurrent Sign-Ins via DeviceCode"
+note = """## Triage and analysis
+
+### Investigating Suspicious Microsoft Entra ID Concurrent Sign-Ins via DeviceCode
+
+### Possible investigation steps
+
+- Review the sign-in logs to assess the context and reputation of the source.ip address.
+- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.
+- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.
+- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
+- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.
+
+### Response and remediation
+
+- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.
+- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
+- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.
+- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
+- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.
+- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event."""
+references = [
+    "https://learn.microsoft.com/en-us/entra/identity/",
+    "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
+    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
+    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
+    "https://www.wiz.io/blog/recent-oauth-attacks-detection-strategies"
+]
+risk_score = 73
+rule_id = "3db029b3-fbb7-4697-ad07-33cbfd5bd080"
+setup = """#### Required Azure Entra Sign-In Logs
+This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.
+"""
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Azure",
+    "Data Source: Entra ID",
+    "Data Source: Entra ID Sign-in",
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-azure.signinlogs-* metadata _id, _version, _index
+
+| where event.category == "authentication" and event.dataset == "azure.signinlogs" and
+        azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow"
+
+| Eval Esql.interactive_logon = CASE(azure.signinlogs.category == "SignInLogs", source.ip, null),
+       Esql.non_interactive_logon = CASE(azure.signinlogs.category ==  "NonInteractiveUserSignInLogs", source.ip, null)
+
+| stats Esql.count_logon = count(*),
+        Esql.timestamp_values = values(@timestamp),
+        Esql.source_ip_count_distinct = count_distinct(source.ip),
+        Esql.is_interactive = count(Esql.interactive_logon),
+        Esql.is_non_interactive = count(Esql.non_interactive_logon),
+        Esql.user_agent_count_distinct = COUNT_DISTINCT(user_agent.original),
+        Esql.user_agent_values = VALUES(user_agent.original),
+        Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name),
+        Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_id),
+        Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),
+        Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement),
+        Esql.azure_signinlogs_properties_tenant_id = values(azure.tenant_id),
+        Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),
+        Esql.message_values = values(message),
+        Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),
+        Esql.source_ip_values = VALUES(source.ip) by azure.signinlogs.properties.session_id, azure.signinlogs.identity
+
+| where Esql.is_interactive >= 2 and Esql.is_non_interactive >= 1 and (Esql.source_ip_count_distinct >= 2 or Esql.user_agent_count_distinct >= 2)
+| keep
+       Esql.*,
+       azure.signinlogs.properties.session_id,
+       azure.signinlogs.identity
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1566"
+name = "Phishing"
+reference = "https://attack.mitre.org/techniques/T1566/"
+[[rule.threat.technique.subtechnique]]
+id = "T1566.002"
+name = "Spearphishing Link"
+reference = "https://attack.mitre.org/techniques/T1566/002/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/azure/credential_access_entra_id_excessive_account_lockouts.toml

@@ -2,9 +2,9 @@
 creation_date = "2025/07/01"
 integration = ["azure"]
 maturity = "production"
-min_stack_version = "8.19.7"
+min_stack_version = "9.0.0"
 min_stack_comments = "Bug fix in threshold rules."
-updated_date = "2025/11/13"
+updated_date = "2025/12/08"
 
 [rule]
 author = ["Elastic"]