[Detection Rules] Adding Documents for v8.19.31 Pre-Built Detection Rules

docs/detections/prebuilt-rules/downloadable-packages/8-19-31/prebuilt-rule-8-19-31-entra-id-high-risk-sign-in.asciidoc

@@ -0,0 +1,127 @@
+[[prebuilt-rule-8-19-31-entra-id-high-risk-sign-in]]
+=== Entra ID High Risk Sign-in
+
+Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-azure.signinlogs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk
+* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection
+* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Identity and Access Audit
+* Resources: Investigation Guide
+* Tactic: Initial Access
+
+*Version*: 113
+
+*Rule authors*: 
+
+* Elastic
+* Willem D'Haese
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID High Risk Sign-in*
+
+
+This rule detects high-risk sign-ins in Microsoft Entra ID as identified by Identity Protection. These sign-ins are flagged with a risk level of `high` during the authentication process, indicating a strong likelihood of compromise based on Microsoft's machine learning and heuristics. This alert is valuable for identifying accounts under active attack or compromise using valid credentials.
+
+
+*Possible investigation steps*
+
+
+- Review the `azure.signinlogs.properties.user_id` and associated identity fields to determine the impacted user.
+- Inspect the `risk_level_during_signin` field and confirm it is set to `high`. If `risk_level_aggregated` is also present and high, this suggests sustained risk across multiple sign-ins.
+- Check `source.ip`, `source.geo.country_name`, and `source.as.organization.name` to evaluate the origin of the sign-in attempt. Flag unexpected geolocations or ASNs (e.g., anonymizers or residential ISPs).
+- Review the `device_detail` fields such as `operating_system` and `browser` for new or unrecognized devices.
+- Validate the `client_app_used` (e.g., legacy protocols, desktop clients) and `app_display_name` (e.g., Office 365 Exchange Online) to assess if risky legacy methods were involved.
+- Examine `applied_conditional_access_policies` to verify if MFA or blocking policies were triggered or bypassed.
+- Check `authentication_details.authentication_method` to see if multi-factor authentication was satisfied (e.g., "Mobile app notification").
+- Correlate this activity with other alerts or sign-ins from the same account within the last 24–48 hours.
+- Contact the user to confirm if the sign-in was expected. If not, treat the account as compromised and proceed with containment.
+
+
+*False positive analysis*
+
+
+- Risky sign-ins may be triggered during legitimate travel, VPN use, or remote work scenarios from unusual locations.
+- In some cases, users switching devices or networks rapidly may trigger high-risk scores.
+- Automated scanners or penetration tests using known credentials may mimic high-risk login behavior.
+- Sign-ins already marked `risk_state` as `remediated`, `dismissed`, or `confirmedSafe` by Microsoft Identity Protection are excluded; failed attempts with no aggregated risk and no active risk state are also excluded.
+
+
+*Response and remediation*
+
+
+- If compromise is suspected, immediately disable the user account and revoke active sessions and tokens.
+- Initiate credential reset and ensure multi-factor authentication is enforced.
+- Review audit logs and sign-in history for the account to assess lateral movement or data access post sign-in.
+- Inspect activity on services such as Exchange, SharePoint, or Azure resources to understand the impact.
+- Determine if the attacker leveraged other accounts or escalated privileges.
+- Use the incident findings to refine conditional access policies, such as enforcing MFA for high-risk sign-ins or blocking legacy protocols.
+- Review and tighten policies that allow sign-ins from high-risk geographies or unknown devices.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:azure.signinlogs and
+  (
+    azure.signinlogs.properties.risk_level_during_signin:high or
+    azure.signinlogs.properties.risk_level_aggregated:high
+  ) and
+  not (event.outcome:failure and azure.signinlogs.properties.risk_level_aggregated:none and azure.signinlogs.properties.risk_state:none) and
+  not azure.signinlogs.properties.risk_state:(remediated or dismissed or confirmedSafe)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/

docs/detections/prebuilt-rules/downloadable-packages/8-19-31/prebuilt-rule-8-19-31-gcp-iam-service-account-impersonation-role-granted.asciidoc

@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-31-gcp-iam-service-account-impersonation-role-granted]]
+=== GCP IAM Service Account Impersonation Role Granted
+
+Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and "roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account, escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-gcp.audit-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://securitylabs.datadoghq.com/cloud-security-atlas/attacks/backdooring-service-account/
+* https://stratus-red-team.cloud/attack-techniques/GCP/gcp.persistence.backdoor-service-account-policy/
+* https://cloud.google.com/iam/docs/service-account-impersonation
+* https://cloud.google.com/iam/docs/audit-logging/examples-service-accounts
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: GCP
+* Data Source: GCP Audit Logs
+* Data Source: Google Cloud Platform
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+* Aryu Zaw
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating GCP IAM Service Account Impersonation Role Granted*
+
+
+Granting an impersonation role on a service account lets the bound member obtain that service account's credentials
+without creating a long-lived key. `roles/iam.serviceAccountTokenCreator` and `roles/iam.serviceAccountOpenIdTokenCreator`
+allow minting OAuth2 access tokens and OpenID Connect identity tokens, while `roles/iam.serviceAccountUser` allows the
+member to attach (actAs) the service account to new resources. Adversaries abuse these grants to pivot to a
+higher-privileged identity, escalate privileges, and persist in a way that is unaffected by key rotation or password
+resets.
+
+
+*Possible investigation steps*
+
+
+- Identify the granting principal via `user.email` and `user.id` and confirm whether that identity is expected to modify
+IAM policy on service accounts.
+- Review the target service account in `gcp.audit.resource_name` and determine the permissions it holds. Impersonating a
+service account with broad project or organization roles represents a significant escalation.
+- Inspect the granted binding in `gcp.audit.request` / `gcp.audit.response` to identify the member that was added
+(`user:`, `serviceAccount:`, `group:`, or an external domain). External or newly created members are higher risk.
+- Examine `gcp.audit.request_metadata.caller_ip` and `gcp.audit.request_metadata.caller_supplied_user_agent` to assess
+whether the change originated from an expected location or tool.
+- Correlate with recent activity by the granting principal, such as service account key creation, custom role creation,
+or `GenerateAccessToken` / `GenerateIdToken` calls that use the newly granted impersonation rights.
+
+
+*False positive analysis*
+
+
+- Terraform, Deployment Manager, and CI/CD service accounts commonly grant serviceAccountUser and
+serviceAccountTokenCreator as part of normal provisioning. Baseline these principals and exclude them with exceptions.
+- One-time grants during application onboarding or delegation may be legitimate. Validate against change management
+before escalating.
+
+
+*Response and remediation*
+
+
+- If the grant is unauthorized, remove the impersonation binding from the service account's IAM policy.
+- Revoke any access or identity tokens issued for the impacted service account and review its recent activity for abuse.
+- Investigate the granting principal for compromise, rotate its credentials if necessary, and review what other IAM
+changes it has made.
+- Restrict who can set IAM policy on service accounts and require justification or approval for impersonation grants.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset: "gcp.audit"
+  and event.action: google.iam.admin.v*.SetIAMPolicy
+  and event.outcome: "success"
+  and gcp.audit.service_data.policy_delta.binding_deltas:{
+    action: "ADD" and
+    role: (
+      "roles/iam.serviceAccountTokenCreator" or
+      "roles/iam.serviceAccountUser" or
+      "roles/iam.serviceAccountOpenIdTokenCreator"
+    )
+  }
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/