Update latest docs (#6849)

Author: tradebot-elastic

docs/detections/prebuilt-rules/downloadable-packages/8-16-14/prebuilt-rule-8-16-14-backup-deletion-with-wbadmin.asciidoc

@@ -0,0 +1,135 @@
+[[prebuilt-rule-8-16-14-backup-deletion-with-wbadmin]]
+=== Backup Deletion with Wbadmin
+
+Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other malware may do this to prevent system recovery.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Backup Deletion with Wbadmin*
+
+
+Windows Server Backup stores the details about your backups (what volumes are backed up and where the backups are located) in a file called a backup catalog, which ransomware victims can use to recover corrupted backup files. Deleting these files is a common step in threat actor playbooks.
+
+This rule identifies the deletion of the backup catalog using the `wbadmin.exe` utility.
+
+
+*Possible investigation steps*
+
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+- Check if any files on the host machine have been encrypted.
+
+
+*False positive analysis*
+
+
+- Administrators can use this command to delete corrupted catalogs, but overall the activity is unlikely to be legitimate.
+
+
+*Related rules*
+
+
+- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9
+- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
+- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
+- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
+- If any backups were affected:
+  - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  (process.name : "wbadmin.exe" or ?process.pe.original_file_name == "WBADMIN.EXE") and
+  process.args : ("catalog", "backup", "systemstatebackup") and process.args : "delete"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/

docs/detections/prebuilt-rules/downloadable-packages/8-16-14/prebuilt-rule-8-16-14-microsoft-entra-id-sharepoint-access-for-user-principal-via-auth-broker.asciidoc

@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-16-14-microsoft-entra-id-sharepoint-access-for-user-principal-via-auth-broker]]
+=== Microsoft Entra ID SharePoint Access for User Principal via Auth Broker
+
+This rule detects non-interactive authentication activity against SharePoint Online (`Office 365 SharePoint Online`) by a user principal via the `Microsoft Authentication Broker` application. The session leverages a refresh token or Primary Refresh Token (PRT) without interactive sign-in, often used in OAuth phishing or token replay scenarios.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* 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://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+* https://github.com/dirkjanm/ROADtools
+* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/
+
+*Tags*: 
+
+* Domain: Cloud
+* Use Case: Identity and Access Audit
+* Tactic: Collection
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Microsoft Entra ID SharePoint Access for User Principal via Auth Broker*
+
+
+This rule identifies non-interactive sign-ins to SharePoint Online via the Microsoft Authentication Broker application using a refresh token or Primary Refresh Token (PRT). This type of activity may indicate token replay attacks, OAuth abuse, or automated access from previously consented apps or stolen sessions.
+
+This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms rule] that detects the first occurrence of a user principal name accessing SharePoint Online via the Microsoft Authentication Broker application in the last 14 days.
+
+
+*Possible Investigation Steps:*
+
+
+- `azure.signinlogs.properties.user_principal_name`: Identify the user involved. Investigate whether this user typically accesses SharePoint or if this is an anomaly.
+- `azure.signinlogs.properties.app_display_name`: Verify the application used (e.g., Authentication Broker). Determine if the app is expected for SharePoint access in your environment.
+- `azure.signinlogs.properties.resource_display_name`: Review the resource being accessed. SharePoint activity should be aligned with job roles or historical usage.
+- `azure.signinlogs.properties.incoming_token_type`: Indicates the token type used. Look for `refreshToken` or `primaryRefreshToken`, which may point to token replay or silent access.
+- `azure.signinlogs.properties.is_interactive`: If false, indicates the sign-in was non-interactive. Correlate with recent sign-ins to understand if a prior session may have been reused.
+- `user_agent.original`: Analyze the user agent string for automation indicators (e.g., scripts, unusual clients). Compare with what’s typical for the user or device.
+- `source.ip`: Check the originating IP address. Investigate if the IP is associated with data centers, VPNs, anonymizers, or is geographically unusual for the user.
+- `source.geo.*`: Evaluate sign-in location details. Determine if the sign-in location aligns with expected travel or usage behavior.
+- `azure.signinlogs.properties.applied_conditional_access_policies`: Review whether Conditional Access policies were triggered or bypassed. Investigate if required controls (like MFA) were applied.
+- `azure.signinlogs.properties.authentication_processing_details`: Review any details about the authentication, such as token type or scopes. This may indicate delegated access or automation patterns.
+
+
+*False Positive Analysis*
+
+
+- Certain MDM or mobile app scenarios may use refresh tokens legitimately via brokered apps.
+- Automated processes using authorized, scripted clients could trigger this activity, especially in developer or operations environments.
+- If Conditional Access policies are configured in “report-only” mode or exempted for trusted apps, activity may appear unusual but be authorized.
+
+
+*Response and Remediation*
+
+
+- If activity appears unauthorized:
+  - Investigate and revoke active sessions or refresh tokens.
+  - Notify the user and validate expected activity.
+  - Review and audit app consent permissions and remove unused or high-risk delegated access.
+- Harden Conditional Access policies to limit non-interactive access to sensitive resources.
+- Monitor for repeated use of the same user agent, IP, or token type across other users to identify broader campaigns.
+- Consider alerting on unusual patterns in sign-in frequency, geography, and application usage for SharePoint and other key services.
+
+
+
+==== Setup
+
+
+
+*Required Microsoft Entra ID Sign-In Logs*
+
+To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "azure.signinlogs"
+    and azure.signinlogs.properties.app_id: "29d9ed98-a469-4536-ade2-f981bc1d605e"
+    and azure.signinlogs.properties.resource_id: "00000003-0000-0ff1-ce00-000000000000"
+    and azure.signinlogs.identity: *
+    and azure.signinlogs.properties.user_principal_name: *
+    and azure.signinlogs.properties.incoming_token_type: ("refreshToken" or "primaryRefreshToken")
+    and azure.signinlogs.properties.is_interactive: false
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Information Repositories
+** ID: T1213
+** Reference URL: https://attack.mitre.org/techniques/T1213/
+* Sub-technique:
+** Name: Sharepoint
+** ID: T1213.002
+** Reference URL: https://attack.mitre.org/techniques/T1213/002/

docs/detections/prebuilt-rules/downloadable-packages/8-16-14/prebuilt-rule-8-16-14-microsoft-graph-first-occurrence-of-client-request.asciidoc

@@ -0,0 +1,126 @@
+[[prebuilt-rule-8-16-14-microsoft-graph-first-occurrence-of-client-request]]
+=== Microsoft Graph First Occurrence of Client Request
+
+This New Terms rule focuses on the first occurrence of a client application ID (azure.graphactivitylogs.properties.app_id) making a request to Microsoft Graph API for a specific tenant ID (azure.tenant_id) and user principal object ID (azure.graphactivitylogs.properties.user_principal_object_id). This rule may helps identify unauthorized access or actions performed by compromised accounts. Advesaries may succesfully compromise a user's credentials and use the Microsoft Graph API to access resources or perform actions on behalf of the user.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-azure.graphactivitylogs-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Azure
+* Data Source: Microsoft Graph
+* Data Source: Microsoft Graph Activity Logs
+* Resources: Investigation Guide
+* Use Case: Identity and Access Audit
+* Tactic: Initial Access
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Microsoft Graph First Occurrence of Client Request*
+
+
+This rule detects the first observed occurrence of a Microsoft Graph API request by a specific client application ID (`azure.graphactivitylogs.properties.app_id`) in combination with a user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) and tenant ID (`azure.tenant_id`) within the last 14 days. This may indicate unauthorized access following a successful phishing attempt, token theft, or abuse of OAuth workflows.
+
+Adversaries frequently exploit legitimate Microsoft or third-party application IDs to avoid raising suspicion during initial access. By using pre-consented or trusted apps to interact with Microsoft Graph, attackers can perform actions on behalf of users without triggering conventional authentication alerts or requiring additional user interaction.
+
+
+*Possible investigation steps*
+
+
+- Review `azure.graphactivitylogs.properties.user_principal_object_id` and correlate with recent sign-in logs for the associated user.
+- Determine whether `azure.graphactivitylogs.properties.app_id` is a known and approved application in your environment.
+- Investigate the `user_agent.original` field for signs of scripted access (e.g., automation tools or libraries).
+- Check the source IP address (`source.ip`) and geolocation data (`source.geo.*`) for unfamiliar origins.
+- Inspect `azure.graphactivitylogs.properties.scopes` to understand the level of access being requested by the app.
+- Examine any follow-up Graph API activity from the same `app_id` or `user_principal_object_id` for signs of data access or exfiltration.
+- Correlate with device or session ID fields (`azure.graphactivitylogs.properties.c_sid`, if present) to detect persistent or repeat activity.
+
+
+*False positive analysis*
+
+
+- First-time use of a legitimate Microsoft or enterprise-approved application.
+- Developer or automation workflows initiating new Graph API requests.
+- Valid end-user activity following device reconfiguration or new client installation.
+- Maintain an allowlist of expected `app_id` values and known developer tools.
+- Suppress detections from known good `user_agent.original` strings or approved source IP ranges.
+- Use device and identity telemetry to distinguish trusted vs. unknown activity sources.
+- Combine with session risk or sign-in anomaly signals where available.
+
+
+*Response and remediation*
+
+
+- Reach out to the user and verify whether they authorized the application access.
+- Revoke active OAuth tokens and reset credentials if unauthorized use is confirmed.
+- Search for additional Graph API calls made by the same `app_id` or `user_principal_object_id`.
+- Investigate whether sensitive resources (mail, files, Teams, contacts) were accessed.
+- Apply Conditional Access policies to limit Graph API access by app type, IP, or device state.
+- Restrict user consent for third-party apps and enforce admin approval workflows.
+- Monitor usage of new or uncommon `app_id` values across your tenant.
+- Provide user education on OAuth phishing tactics and reporting suspicious prompts.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "azure.graphactivitylogs"
+    and event.type: "access"
+    and azure.graphactivitylogs.properties.c_idtyp: "user"
+    and azure.graphactivitylogs.properties.client_auth_method: 0
+    and http.response.status_code: 200
+    and url.domain: "graph.microsoft.com"
+
+----------------------------------
+
+*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/