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

nldcsc_elastic_rules/rules/integrations/azure/initial_access_entra_id_actor_token_user_impersonation_abuse.toml

@@ -0,0 +1,134 @@
+[metadata]
+creation_date = "2025/09/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend
+mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf
+of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some
+legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which
+allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft.
+"""
+false_positives = [
+    """
+    Creating specific groups via the Exchange Online PowerShell module will make Exchange use an Actor token on your
+    behalf. The rule excludes group operations and directory feature operations to reduce false positives from these
+    legitimate administrative activities.
+    """,
+]
+from = "now-9m"
+interval = "8m"
+language = "esql"
+license = "Elastic License v2"
+name = "Entra ID Actor Token User Impersonation Abuse"
+note = """## Triage and analysis
+
+### Investigating Entra ID Actor Token User Impersonation Abuse
+
+This rule detects when Microsoft services use actor tokens to perform operations in audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) communication. They appear with a mismatch: the service's display name but the impersonated user's UPN. While some operations legitimately use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed attackers to obtain Global Admin privileges across any Entra ID tenant. Note that this vulnerability has been patched by Microsoft as of September 2025.
+
+### Possible investigation steps
+
+- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify which service principals are exhibiting this behavior.
+- Check the `azure.auditlogs.properties.initiated_by.user.displayName` to confirm these are legitimate Microsoft services.
+- Analyze the actions performed by these service principals - look for privilege escalations, permission grants, or unusual administrative operations.
+- Review the timing and frequency of these events to identify potential attack patterns or automated exploitation.
+- Cross-reference with recent administrative changes or service configurations that might explain legitimate use cases.
+- Check if any new applications or service principals were registered recently that could be related to this activity.
+- Investigate any correlation with other suspicious authentication events or privilege escalation attempts in your tenant.
+
+### False positive analysis
+
+- Legitimate Microsoft service migrations or updates may temporarily exhibit this behavior.
+- Third-party integrations using Microsoft Graph or other APIs might trigger this pattern during normal operations.
+- Automated administrative tools or scripts using service principal authentication could be misconfigured.
+
+### Response and remediation
+
+- Immediately review and audit all service principal permissions and recent consent grants in your Entra ID tenant.
+- Disable or restrict any suspicious service principals exhibiting this behavior until verified.
+- Review and revoke any unnecessary application permissions, especially those with high privileges.
+- Enable and review Entra ID audit logs for any permission grants or role assignments made by these service principals.
+- Implement Conditional Access policies to restrict service principal authentication from unexpected locations or conditions.
+- Enable Entra ID Identity Protection to detect and respond to risky service principal behaviors.
+- Review and harden application consent policies to prevent unauthorized service principal registrations.
+- Consider implementing privileged identity management (PIM) for service principal role assignments.
+"""
+references = [
+    "https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/",
+    "https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-55241"
+]
+risk_score = 47
+rule_id = "8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Azure",
+    "Data Source: Entra ID",
+    "Data Source: Entra Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-azure.auditlogs-* metadata _id, _version, _index
+| where azure.auditlogs.properties.initiated_by.user.displayName in (
+    "Office 365 Exchange Online",
+    "Skype for Business Online",
+    "Dataverse",
+    "Office 365 SharePoint Online",
+    "Microsoft Dynamics ERP"
+  ) and
+  not azure.auditlogs.operation_name like "*group*" and
+  azure.auditlogs.operation_name != "Set directory feature on tenant"
+  and azure.auditlogs.properties.initiated_by.user.userPrincipalName rlike ".+@[A-Za-z0-9.]+\\.[A-Za-z]{2,}"
+| keep
+    _id,
+    @timestamp,
+    azure.*,
+    client.*,
+    event.*,
+    source.*
+'''
+
+
+[[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.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1548"
+name = "Abuse Elevation Control Mechanism"
+reference = "https://attack.mitre.org/techniques/T1548/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/azure/initial_access_entra_id_device_code_auth_with_broker_client.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2024/06/24"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e).
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Entra ID Device Code Auth with Broker Client"
+references =[
+    "https://dirkjanm.io/assets/raw/Phishing%20the%20Phishing%20Resistant.pdf",
+    "https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in",
+    "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
+]
+risk_score = 47
+rule_id = "a83b3dac-325a-11ef-b3e6-f661ea17fbce"
+setup = """
+This rule optionally requires Azure Sign-In logs from the Azure integration. Ensure that the Azure integration is correctly set up and that the required data is being collected.
+"""
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+ event.dataset:(azure.activitylogs or azure.signinlogs)
+    and azure.signinlogs.properties.authentication_protocol:deviceCode
+    and azure.signinlogs.properties.conditional_access_audiences.application_id:29d9ed98-a469-4536-ade2-f981bc1d605e
+    and event.outcome:success or (
+        azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e
+        and azure.activitylogs.properties.authentication_protocol:deviceCode)
+'''
+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 Entra ID Device Code Auth with Broker Client
+
+Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode.
+- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e.
+- 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.
+
+### False positive analysis
+
+- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy.
+- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs.
+- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities.
+- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary.
+- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns.
+
+### 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."""
+
+
+[[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.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.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+[[rule.threat.technique.subtechnique]]
+id = "T1550.001"
+name = "Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1550/001/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/initial_access_entra_id_high_risk_signin.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2021/01/04"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic", "Willem D'Haese"]
+description = """
+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.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.signinlogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft Entra ID High Risk Sign-in"
+note = """## Triage and analysis
+
+### Investigating Microsoft 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.
+- Confirm whether the risk was remediated automatically by Microsoft Identity Protection before proceeding with escalations.
+
+### 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.
+"""
+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",
+]
+risk_score = 73
+rule_id = "37994bca-0611-4500-ab67-5588afe73b77"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "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",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.signinlogs and
+  (
+    azure.signinlogs.properties.risk_level_during_signin:high or
+    azure.signinlogs.properties.risk_level_aggregated:high
+  )
+'''
+
+
+[[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.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/azure/initial_access_entra_id_oauth_user_impersonation_scope.toml

@@ -0,0 +1,167 @@
+[metadata]
+creation_date = "2025/07/03"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/06"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth
+scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized
+access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not
+associated with a specific device or session. This behavior is indicative of potential account compromise or
+unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen
+in the last 10 days, indicating potential abuse or unusual activity.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.signinlogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Entra ID OAuth user_impersonation Scope for Unusual User and Client"
+note = """## Triage and Analysis
+
+### Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client
+
+Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious
+OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where
+the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or
+unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.
+
+### Possible investigation steps
+
+- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow.
+- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user.
+- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access.
+- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies.
+- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.
+- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities.
+- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise.
+
+### False positive analysis
+
+- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
+- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.
+- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
+
+### Response and remediation
+
+- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor.
+- If the OAuth workflow is confirmed to be malicious:
+  - Block the user account and reset the password to prevent further unauthorized access.
+  - Revoke active sessions and refresh tokens associated with the user principal.
+  - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant.
+  - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.
+  - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.
+- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.
+"""
+references = [
+    "https://github.com/Flangvik/TeamFiltration",
+    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
+]
+risk_score = 47
+rule_id = "9563dace-5822-11f0-b1d3-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Use Case: Threat Detection",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Sign-In Logs",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.signinlogs and
+    azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and
+    azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and
+    azure.signinlogs.properties.token_issuer_type: "AzureAD" and
+    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
+    azure.signinlogs.properties.user_type: "Member" and
+    azure.signinlogs.properties.conditional_access_status: "notApplied" and
+    not user_agent.original: Mozilla*PKeyAuth/1.0 and
+    not azure.signinlogs.properties.device_detail.operating_system: (Ios* or Android*) and
+    event.outcome: "success"
+    and not azure.signinlogs.properties.app_id: (
+        "a5f63c0-b750-4f38-a71c-4fc0d58b89e2" or
+        "6bc3b958-689b-49f5-9006-36d165f30e00" or
+        "66a88757-258c-4c72-893c-3e8bed4d6899" or
+        "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or
+        "0000000c-0000-0000-c000-000000000000"
+    )
+'''
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "azure.correlation_id",
+    "azure.signinlogs.category",
+    "azure.signinlogs.identity",
+    "azure.signinlogs.properties.app_display_name",
+    "azure.signinlogs.properties.app_id",
+    "azure.signinlogs.properties.app_owner_tenant_id",
+    "azure.signinlogs.properties.authentication_requirement",
+    "azure.signinlogs.properties.client_credential_type",
+    "azure.signinlogs.properties.conditional_access_status",
+    "azure.signinlogs.properties.device_detail.operating_system",
+    "azure.signinlogs.properties.is_interactive",
+    "azure.signinlogs.properties.session_id",
+    "azure.signinlogs.properties.user_principal_name",
+    "azure.signinlogs.properties.user_type",
+    "azure.signinlogs.result_signature",
+    "azure.tenant_id",
+    "source.address",
+    "user.id"
+]
+
+
+[[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.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+[[rule.threat.technique.subtechnique]]
+id = "T1550.001"
+name = "Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1550/001/"
+
+[[rule.threat.technique]]
+id = "T1656"
+name = "Impersonation"
+reference = "https://attack.mitre.org/techniques/T1656/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.signinlogs.properties.user_principal_name", "azure.signinlogs.properties.app_id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"