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

nldcsc_elastic_rules/rules/integrations/o365/credential_access_microsoft_365_excessive_account_lockouts.toml

@@ -0,0 +1,155 @@
+[metadata]
+creation_date = "2025/05/10"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login
+errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.
+"""
+from = "now-9m"
+interval = "8m"
+language = "esql"
+license = "Elastic License v2"
+name = "Multiple Microsoft 365 User Account Lockouts in Short Time Window"
+note = """## Triage and Analysis
+
+### Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window
+
+Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.
+
+This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context.
+
+### Investigation Steps
+
+- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)?
+- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers.
+- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation.
+- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly?
+- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs.
+- Correlate with any recent detection of password spraying or credential stuffing activity.
+- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.).
+- Check for any successful logins from the same IP or ASN after the lockouts.
+
+### False Positive Analysis
+
+- Automated systems with stale credentials may cause repeated failed logins.
+- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts.
+- Red team exercises or penetration tests may resemble the same lockout pattern.
+- Some organizations may have a high volume of lockouts due to user behavior or legacy systems.
+
+### Response Recommendations
+
+- Notify affected users and confirm whether activity was expected or suspicious.
+- Lock or reset credentials for impacted accounts.
+- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.
+- Strengthen lockout and retry delay policies if necessary.
+- Review the originating application(s) involved via `request_types`.
+"""
+references = [
+    "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray",
+    "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties",
+    "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/",
+    "https://github.com/0xZDH/Omnispray",
+    "https://github.com/0xZDH/o365spray",
+]
+risk_score = 47
+rule_id = "de67f85e-2d43-11f0-b8c9-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: SaaS",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Use Case: Threat Detection",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-o365.audit-*
+| mv_expand event.category
+| eval
+    Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)
+| where
+    event.dataset == "o365.audit" and
+    event.category == "authentication" and
+    event.provider in ("AzureActiveDirectory", "Exchange") and
+    event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and
+    to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*||.*login.*)" and
+    o365.audit.LogonError == "IdsLocked" and
+    to_lower(o365.audit.UserId) != "not available" and
+    o365.audit.Target.Type in ("0", "2", "6", "10") and
+    source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK"
+| stats
+    Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)),
+    Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)),
+    Esql.source_ip_values = values(source.ip),
+    Esql.source_ip_count_distinct = count_distinct(source.ip),
+    Esql.source_as_organization_name_values = values(source.`as`.organization.name),
+    Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),
+    Esql.source_geo_country_name_values = values(source.geo.country_name),
+    Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),
+    Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)),
+    Esql.timestamp_first_seen = min(@timestamp),
+    Esql.timestamp_last_seen = max(@timestamp),
+    Esql.event_count = count(*)
+  by Esql.time_window_date_trunc
+| eval
+    Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen)
+| keep
+    Esql.time_window_date_trunc,
+    Esql_priv.o365_audit_UserId_count_distinct,
+    Esql_priv.o365_audit_UserId_values,
+    Esql.source_ip_values,
+    Esql.source_ip_count_distinct,
+    Esql.source_as_organization_name_values,
+    Esql.source_as_organization_name_count_distinct,
+    Esql.source_geo_country_name_values,
+    Esql.source_geo_country_name_count_distinct,
+    Esql.o365_audit_ExtendedProperties_RequestType_values,
+    Esql.timestamp_first_seen,
+    Esql.timestamp_last_seen,
+    Esql.event_count,
+    Esql.event_duration_seconds
+| where
+    Esql_priv.o365_audit_UserId_count_distinct >= 10 and
+    Esql.event_count >= 10 and
+    Esql.event_duration_seconds <= 300
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.004"
+name = "Credential Stuffing"
+reference = "https://attack.mitre.org/techniques/T1110/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/o365/credential_access_microsoft_365_potential_user_account_brute_force.toml

@@ -0,0 +1,181 @@
+[metadata]
+creation_date = "2020/11/30"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/07/16"
+
+[rule]
+author = ["Elastic", "Willem D'Haese", "Austin Songer"]
+description = """
+Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that
+match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force
+authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.
+"""
+false_positives = [
+    """
+    Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
+    positives.
+    """,
+]
+from = "now-60m"
+interval = "10m"
+language = "esql"
+license = "Elastic License v2"
+name = "Potential Microsoft 365 User Account Brute Force"
+note = """## Triage and Analysis
+
+### Investigating Potential Microsoft 365 User Account Brute Force
+
+Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.
+
+### Possible investigation steps
+
+- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins).
+- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords.
+- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers.
+- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation.
+- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins.
+- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded.
+- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA.
+
+### False positive analysis
+
+- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster.
+- Penetration testing or red team simulations may resemble spray activity.
+- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns.
+
+### Response and remediation
+
+- Initiate an internal incident ticket and inform the affected identity/IT team.
+- Temporarily disable impacted user accounts if compromise is suspected.
+- Investigate whether any login attempts succeeded after the spray window.
+- Block the offending IPs or ASN temporarily via firewall or conditional access policies.
+- Rotate passwords for all targeted accounts and audit for password reuse.
+- Enforce or verify MFA is enabled for all user accounts.
+- Consider deploying account lockout or progressive delay mechanisms if not already enabled.
+"""
+references = [
+    "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray",
+    "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties",
+    "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/",
+    "https://github.com/0xZDH/Omnispray",
+    "https://github.com/0xZDH/o365spray",
+]
+risk_score = 47
+rule_id = "26f68dba-ce29-497b-8e13-b4fde1db5a2d"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: SaaS",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "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-o365.audit-*
+| mv_expand event.category
+| eval
+    Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp),
+    Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId),
+    Esql.o365_audit_LogonError = o365.audit.LogonError,
+    Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType)
+| where
+    event.dataset == "o365.audit" and
+    event.category == "authentication" and
+    event.provider in ("AzureActiveDirectory", "Exchange") and
+    event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and
+    Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*||.*login.*)" and
+    Esql.o365_audit_LogonError != "IdsLocked" and
+    Esql.o365_audit_LogonError not in (
+        "EntitlementGrantsNotFound",
+        "UserStrongAuthEnrollmentRequired",
+        "UserStrongAuthClientAuthNRequired",
+        "InvalidReplyTo",
+        "SsoArtifactExpiredDueToConditionalAccess",
+        "PasswordResetRegistrationRequiredInterrupt",
+        "SsoUserAccountNotFoundInResourceTenant",
+        "UserStrongAuthExpired",
+        "CmsiInterrupt"
+    ) and
+    Esql_priv.o365_audit_UserId_lower != "not available" and
+    o365.audit.Target.Type in ("0", "2", "6", "10")
+| stats
+    Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower),
+    Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower),
+    Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError),
+    Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError),
+    Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower),
+    Esql.source_ip_values = values(source.ip),
+    Esql.source_ip_count_distinct = count_distinct(source.ip),
+    Esql.source_as_organization_name_values = values(source.`as`.organization.name),
+    Esql.source_geo_country_name_values = values(source.geo.country_name),
+    Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),
+    Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),
+    Esql.timestamp_first_seen = min(@timestamp),
+    Esql.timestamp_last_seen = max(@timestamp),
+    Esql.event_count = count(*)
+  by Esql.time_window_date_trunc
+| eval
+    Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen),
+    Esql.brute_force_type = case(
+        Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, "password_spraying",
+        Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, "credential_stuffing",
+        Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, "password_guessing",
+        "other"
+    )
+| keep
+    Esql.time_window_date_trunc,
+    Esql.o365_audit_UserId_lower_count_distinct,
+    Esql_priv.o365_audit_UserId_lower_values,
+    Esql.o365_audit_LogonError_values,
+    Esql.o365_audit_LogonError_count_distinct,
+    Esql.o365_audit_ExtendedProperties_RequestType_values,
+    Esql.source_ip_values,
+    Esql.source_ip_count_distinct,
+    Esql.source_as_organization_name_values,
+    Esql.source_geo_country_name_values,
+    Esql.source_geo_country_name_count_distinct,
+    Esql.source_as_organization_name_count_distinct,
+    Esql.timestamp_first_seen,
+    Esql.timestamp_last_seen,
+    Esql.event_duration_seconds,
+    Esql.event_count,
+    Esql.brute_force_type
+| where Esql.brute_force_type != "other"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.004"
+name = "Credential Stuffing"
+reference = "https://attack.mitre.org/techniques/T1110/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2021/05/17"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Identifies accounts with a high number of single sign-on (SSO) logon errors. Excessive logon errors may indicate an
+attempt to brute force a password or SSO token.
+"""
+false_positives = [
+    """
+    Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
+    positives.
+    """,
+]
+from = "now-9m"
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "O365 Excessive Single Sign-On Logon Errors"
+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 Excessive Single Sign-On Logon Errors
+
+Single Sign-On (SSO) in O365 streamlines user access by allowing one set of credentials for multiple applications. However, adversaries may exploit this by attempting brute force attacks to gain unauthorized access. The detection rule monitors for frequent SSO logon errors, signaling potential abuse, and helps identify compromised accounts by flagging unusual authentication patterns.
+
+### Possible investigation steps
+
+- Review the specific account(s) associated with the excessive SSO logon errors by examining the event logs filtered by the query fields, particularly focusing on the o365.audit.LogonError field with the value "SsoArtifactInvalidOrExpired".
+- Analyze the timestamps of the logon errors to determine if there is a pattern or specific time frame when the errors are occurring, which might indicate a targeted attack.
+- Check for any recent changes or unusual activities in the affected account(s), such as password changes, unusual login locations, or device changes, to assess if the account might be compromised.
+- Investigate the source IP addresses associated with the logon errors to identify if they are from known malicious sources or unusual locations for the user.
+- Correlate the logon error events with other security alerts or logs from the same time period to identify any related suspicious activities or potential indicators of compromise.
+- Contact the user(s) of the affected account(s) to verify if they experienced any issues with their account access or if they recognize the logon attempts, which can help determine if the activity is legitimate or malicious.
+
+### False positive analysis
+
+- High volume of legitimate user logins: Users who frequently log in and out of multiple O365 applications may trigger excessive logon errors. To manage this, create exceptions for known high-activity accounts.
+- Automated scripts or applications: Some automated processes may use outdated or incorrect credentials, leading to repeated logon errors. Identify and update these scripts to prevent false positives.
+- Password changes: Users who recently changed their passwords might experience logon errors if they have not updated their credentials across all devices and applications. Encourage users to update their credentials promptly.
+- Network issues: Temporary network disruptions can cause authentication errors. Monitor network stability and consider excluding errors during known network maintenance periods.
+- Multi-factor authentication (MFA) misconfigurations: Incorrect MFA settings can lead to logon errors. Verify and correct MFA configurations for affected users to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected account by disabling it to prevent further unauthorized access attempts.
+- Conduct a password reset for the compromised account and enforce a strong password policy to mitigate the risk of future brute force attacks.
+- Review and analyze the account's recent activity logs to identify any unauthorized access or data exfiltration attempts.
+- Implement multi-factor authentication (MFA) for the affected account and other high-risk accounts to add an additional layer of security.
+- Notify the user of the affected account about the incident and provide guidance on recognizing phishing attempts and securing their credentials.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Update and enhance monitoring rules to detect similar patterns of excessive SSO logon errors, ensuring early detection of potential brute force attempts.
+
+## Setup
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+risk_score = 73
+rule_id = "2de10e77-c144-4e69-afb7-344e7127abd0"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:o365.audit and event.provider:AzureActiveDirectory and event.category:authentication and o365.audit.LogonError:"SsoArtifactInvalidOrExpired"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.threshold]
+field = ["user.id"]
+value = 5
+

nldcsc_elastic_rules/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_policy_deletion.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2020/11/19"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, Microsoft 365 includes built-in
+features that help protect users from phishing attacks. Anti-phishing polices increase this protection by refining
+settings to better detect and prevent attacks.
+"""
+false_positives = [
+    """
+    An anti-phishing policy may be deleted by a system or network administrator. Verify that the configuration change
+    was expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+from = "now-9m"
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft 365 Exchange Anti-Phish Policy Deletion"
+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 Exchange Anti-Phish Policy Deletion
+
+Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion.
+- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp.
+- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times.
+- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings.
+- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents.
+- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process.
+
+### False positive analysis
+
+- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions.
+- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions.
+- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions.
+- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration.
+- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups.
+- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures.
+- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed.
+- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies.
+
+## 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/powershell/module/exchange/remove-antiphishpolicy?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide",
+]
+risk_score = 47
+rule_id = "d68eb1b5-5f1c-4b6d-9e63-5b6b145cd4aa"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-AntiPhishPolicy" and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/o365/defense_evasion_microsoft_365_exchange_anti_phish_rule_mod.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2020/11/19"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in
+features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining
+settings to better detect and prevent attacks.
+"""
+false_positives = [
+    """
+    An anti-phishing rule may be deleted by a system or network administrator. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+from = "now-9m"
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft 365 Exchange Anti-Phish Rule Modification"
+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 Exchange Anti-Phish Rule Modification
+
+Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert.
+- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule.
+- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern.
+- Identify the user or account associated with the modification by examining the relevant user fields in the event log.
+- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies.
+- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred.
+- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed.
+
+### False positive analysis
+
+- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs.
+- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers.
+- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks.
+- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings.
+- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them.
+- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts.
+- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised.
+- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly.
+- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings.
+
+## 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/powershell/module/exchange/remove-antiphishrule?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/disable-antiphishrule?view=exchange-ps",
+]
+risk_score = 47
+rule_id = "97314185-2568-4561-ae81-f3e480e5e695"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-AntiPhishRule" or "Disable-AntiPhishRule") and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+