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

nldcsc_elastic_rules/rules/integrations/o365/initial_access_entra_id_portal_login_impossible_travel.toml

@@ -0,0 +1,131 @@
+[metadata]
+creation_date = "2024/09/04"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/10/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined
+as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a
+Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from
+a different location.
+"""
+false_positives = [
+    """
+    False positives may occur when users are using a VPN or when users are traveling to different locations for
+    legitimate purposes.
+    """,
+]
+from = "now-15m"
+index = ["logs-o365.audit-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "M365 Identity Login from Impossible Travel Location"
+note = """## Triage and analysis
+
+### Investigating M365 Identity Login from Impossible Travel Location
+
+Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.
+- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.
+- Review the ISP information for the login attempts to identify any unusual or suspicious providers.
+- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.
+- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)
+- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.
+
+### False positive analysis
+
+- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.
+- Mobile access may also result in false positives, as users may log in from various locations while on the go.
+
+### Response and remediation
+
+- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.
+- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.
+- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.
+- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.
+- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.
+"""
+references = ["https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel-"]
+risk_score = 47
+rule_id = "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Use Case: Threat Detection",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:o365.audit and
+    event.provider:AzureActiveDirectory and
+    event.action:UserLoggedIn and
+    event.outcome:success and
+    o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and
+    o365.audit.UserId:(* and not "Not Available") and
+    source.geo.region_iso_code:* and
+    not o365.audit.ApplicationId:(
+        29d9ed98-a469-4536-ade2-f981bc1d605e or
+        38aa3b87-a06d-4817-b275-7a316988d93b or
+        a809996b-059e-42e2-9866-db24b99a9782
+    ) and not o365.audit.ExtendedProperties.RequestType:(
+        "Cmsi:Cmsi" or
+        "Consent:Set" or
+        "Login:reprocess" or
+        "Login:resume" or
+        "MessagePrompt:MessagePrompt" or
+        "SAS:EndAuth"
+    )
+'''
+
+
+[[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.investigation_fields]
+field_names = [
+    "@timestamp",
+    "organization.id",
+    "o365.audit.UserId",
+    "o365.audit.ActorIpAddress",
+    "o365.audit.ApplicationId",
+    "o365.audit.ExtendedProperties.RequestType",
+    "o365.audit.Target.ID",
+    "source.geo.country_name",
+]
+
+[rule.threshold]
+field = ["o365.audit.UserId"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "source.geo.country_name"
+value = 2
+
+

nldcsc_elastic_rules/rules/integrations/o365/initial_access_microsoft_365_entra_oauth_phishing_via_vscode_client.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2025/04/23"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/08"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects potentially suspicious OAuth authorization activity in Microsoft 365 where the Visual Studio Code first-party
+application (client_id = aebc6443-996d-45c2-90f0-388ff96faa56) is used to request access to Microsoft Graph resources.
+While this client ID is legitimately used by Visual Studio Code, threat actors have been observed abusing it in phishing
+campaigns to make OAuth requests appear trustworthy. These attacks rely on redirect URIs such as VSCode Insiders
+redirect location, prompting victims to return an OAuth authorization code that can be exchanged for access tokens. This
+rule may help identify unauthorized use of the VS Code OAuth flow as part of social engineering or credential phishing
+activity.
+"""
+from = "now-25m"
+index = ["logs-o365.audit-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft 365 OAuth Phishing via Visual Studio Code Client"
+note = """## Triage and analysis
+
+### Investigating Microsoft 365 OAuth Phishing via Visual Studio Code Client
+
+This rule identifies successful Microsoft 365 sign-ins where the Visual Studio Code first-party application (`ApplicationId = aebc6443-996d-45c2-90f0-388ff96faa56`) was used to initiate an OAuth 2.0 authorization code flow targeting Microsoft Graph. While this is common for legitimate development workflows, it has been abused in real-world phishing campaigns to trick users into returning authorization codes that attackers can exchange for access tokens.
+
+The behavior is typically seen in targeted attacks where users are lured into clicking a Microsoft login URL that redirects to a legitimate Microsoft URI (such as `insiders.vscode.dev`) and displays an OAuth code. If the user returns this code (e.g., via Signal, WhatsApp, or email), the attacker can use it to gain access to the user’s data via Microsoft Graph APIs — all without prompting for explicit consent or MFA, especially when default or pre-consented apps are abused.
+
+### Possible investigation steps
+
+- Review `user.name` or `o365.audit.UserId` to identify the impacted account.
+- Validate whether the user expected to authorize the Visual Studio Code app at the time of the event.
+- Check if `o365.audit.ActorIpAddress` is an unexpected or geolocated IP — especially outside of corporate ranges or from proxy networks.
+- Look at `user_agent.original` and `o365.audit.DeviceProperties` to determine the device and browser involved — known attacker flows often show Chrome + MacOS or headless browser variants.
+- Confirm the `Target.ID` (Microsoft Graph: `00000003-0000-0000-c000-000000000000`) matches the scope of access the attacker might attempt.
+- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar service principals or devices.
+- Review the `ExtendedProperties.RequestType` = `OAuth2:Authorize` and `ResultStatusDetail` = `Redirect` — this indicates that the user was redirected after authorization, which typically exposes the OAuth `code`.
+
+### False positive analysis
+
+- Developers or IT users intentionally using Visual Studio Code to connect to Microsoft 365 may trigger this rule.
+- Legitimate Visual Studio Code extensions that sync or query Graph API data (e.g., calendars, tasks, cloud-hosted notebooks).
+- Enterprise use cases where VS Code is used for integrated identity workflows.
+- Exclude known user agents and hosts that regularly use Visual Studio Code against Graph.
+- Whitelist specific source IPs or devices tied to developer machines.
+- Correlate with user context and behavior — if the user has no reason to be developing or testing code, the event may be more suspicious.
+- Add exception rules for managed devices or corporate laptops using this flow regularly.
+
+### Response and remediation
+
+- Reach out to the user to confirm if they expected this login or may have shared an OAuth code.
+- Suspend or reset credentials if the login appears suspicious or if the code was likely returned to a third party.
+- Review recent Microsoft Graph activity (email, file access, Teams) for this user and service principal.
+- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access.
+- Add alerts for `ApplicationId = aebc6443-...` combined with low-reputation IPs or unexpected device fingerprints.
+- Require MFA and Conditional Access for all OAuth flows — even for Microsoft first-party apps.
+- Disable or restrict app consent for users, and require admin approval for Graph API scopes.
+- Educate users about OAuth-based phishing techniques — especially those that ask users to share "codes" after clicking a Microsoft login link.
+- Regularly audit `ApplicationId`, `RequestType`, and `ResultStatusDetail` values in `o365.audit` to spot anomalous usage patterns.
+"""
+references = [
+    "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/",
+]
+risk_score = 47
+rule_id = "929d0766-204b-11f0-9c1f-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: SaaS",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Initial Access",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "o365.audit"
+    and event.action: "UserLoggedIn"
+    and o365.audit.ApplicationId: "aebc6443-996d-45c2-90f0-388ff96faa56"
+    and o365.audit.Target.ID: "00000003-0000-0000-c000-000000000000"
+    and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize"
+    and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect"
+    and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[[rule.threat.technique]]
+id = "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/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml

@@ -0,0 +1,154 @@
+[metadata]
+creation_date = "2025/03/24"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries
+may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access
+resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically
+via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access
+resources in Microsoft 365 on-behalf-of the user.
+"""
+from = "now-9m"
+index = ["logs-o365.audit-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft 365 Illicit Consent Grant via Registered Application"
+note = """## Triage and analysis
+
+### Investigating Microsoft 365 Illicit Consent Grant via Registered Application
+
+Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL.
+
+This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days.
+
+#### Possible investigation steps
+
+- **Review the app in Entra ID**:
+  - Go to **Enterprise Applications** in the Azure portal.
+  - Search for the `AppId` or name from `o365.audit.ObjectId`.
+  - Review granted API permissions and whether admin consent was required.
+  - Check the `Publisher` and `Verified` status.
+
+- **Assess the user who granted consent**:
+  - Investigate `o365.audit.UserId` (e.g., `terrance.dejesus@...`) for signs of phishing or account compromise.
+  - Check if the user was targeted in recent phishing simulations or campaigns.
+  - Review the user’s sign-in logs for suspicious geolocation, IP, or device changes.
+
+- **Determine scope and risk**:
+  - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level.
+  - If `offline_access` or `Mail.Read` was granted, consider potential data exposure.
+  - Cross-reference affected `Target` objects with known business-critical assets or data owners.
+
+- **Correlate additional telemetry**:
+  - Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns.
+  - Search for `AppId` across your tenant to determine how widely it's used.
+
+### False positive analysis
+
+- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department.
+- Consent reasons like `WindowsAzureActiveDirectoryIntegratedApp` could relate to integrated services, though these still require verification.
+
+### Response and remediation
+
+- **If the app is confirmed malicious**:
+  - Revoke OAuth consent using the [Microsoft Graph API](https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-delete).
+  - Remove any related service principals from Entra ID.
+  - Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies.
+  - Revoke refresh tokens and require reauthentication for affected users.
+  - Notify end-users and IT of the potential exposure.
+  - Activate your phishing or OAuth abuse response playbook.
+
+- **Prevent future misuse**:
+  - Enable the [Admin consent workflow](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) to restrict user-granted consent.
+  - Audit and reduce overprivileged applications in your environment.
+  - Consider using Defender for Cloud Apps OAuth app governance.
+
+"""
+references = [
+    "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices",
+    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide",
+    "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/",
+    "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps",
+    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema",
+]
+risk_score = 47
+rule_id = "0c3c80de-08c2-11f0-bd11-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Initial Access",
+    "Tactic: Credential Access",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "o365.audit"
+  and o365.audit.Actor.Type: 5
+  and event.action: "Consent to application."
+  and event.outcome: "success"
+  and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10)
+'''
+
+
+[[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/"
+[[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.investigation_fields]
+field_names = [
+    "@timestamp",
+    "event.action",
+    "event.outcome",
+    "o365.audit.UserId",
+    "o365.audit.ObjectId",
+    "o365.audit.Actor.Type",
+    "o365.audit.Target.Type",
+    "o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue",
+    "o365.audit.ExtendedProperties.additionalDetails",
+    "cloud.region"
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["o365.audit.UserId", "o365.audit.ObjectId"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+

nldcsc_elastic_rules/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml

@@ -0,0 +1,87 @@
+[metadata]
+creation_date = "2021/07/15"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies
+per the Security Compliance Center.
+"""
+false_positives = ["A user sending emails using personal distribution folders may trigger the event."]
+from = "now-9m"
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft 365 User Restricted from Sending Email"
+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 Microsoft 365 User Restricted from Sending Email
+
+Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
+
+### Possible investigation steps
+
+- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly.
+- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert.
+- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing.
+- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts.
+- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack.
+
+### False positive analysis
+
+- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns.
+- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits.
+- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate.
+- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed.
+- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions.
+
+### Response and remediation
+
+- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam.
+- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access.
+- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised.
+- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence.
+- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident.
+
+## Setup
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+references = [
+    "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy",
+    "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference",
+]
+risk_score = 47
+rule_id = "0136b315-b566-482f-866c-1d8e2477ba16"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Use Case: Configuration Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"User restricted from sending email" and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2022/01/12"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to
+stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a
+malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent
+malware infections and Business Email Compromise attacks.
+"""
+false_positives = ["Legitimate files reported by the users"]
+from = "now-9m"
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "O365 Email Reported by User as Malware or Phish"
+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 O365 Email Reported by User as Malware or Phish
+
+Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution.
+
+### Possible investigation steps
+
+- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email.
+- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included.
+- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt.
+- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat.
+- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments.
+- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user.
+
+### False positive analysis
+
+- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged.
+- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts.
+- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors.
+- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives.
+- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time.
+
+### Response and remediation
+
+- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access.
+- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them.
+- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools.
+- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts.
+- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls.
+- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future.
+
+## Setup
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://support.microsoft.com/en-us/office/use-the-report-message-add-in-b5caa9f1-cdf3-4443-af8c-ff724ea719d2?ui=en-us&rs=en-us&ad=us",
+]
+risk_score = 47
+rule_id = "5930658c-2107-4afc-91af-e0e55b7f7184"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.action:AlertTriggered and rule.name:"Email reported by user as malware or phish"
+'''
+
+
+[[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.001"
+name = "Spearphishing Attachment"
+reference = "https://attack.mitre.org/techniques/T1566/001/"
+
+[[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/"
+