[New Rule] M365 SharePoint Site Sharing Policy Weakened

[terrancedejesus]

Pull Request

Issue link(s):

• [New Rule] Microsoft 365 - Sharing Policy Change #1350

Summary - What I changed

Adds a new detection rule for Microsoft 365 SharePoint/OneDrive SharingPolicyChanged events that indicate a weakened security posture.

A blanket SharingPolicyChanged rule is too noisy, this event fires for every sharing policy modification across all SharePoint sites, including routine administrative changes. The alternative detection approaches have limitations:

• New Terms rule type cannot be used because the relevant data lives in dynamic field names (e.g., o365.audit.ModifiedProperties.ShareWithGuests.NewValue), not in field values. New Terms only tracks new values, not new field keys.
• ES|QL cannot parse the dynamic ModifiedProperties.* field name structure at query time.

The solution is a scenario-driven approach: target specific ModifiedProperties field names where a value transition from restrictive → permissive represents a meaningful security posture degradation.

ModifiedProperties field schema

The M365 audit log stores policy changes in o365.audit.ModifiedProperties as dynamic keys:

o365.audit.ModifiedProperties.<SettingName>.NewValue
o365.audit.ModifiedProperties.<SettingName>.OldValue

Where <SettingName> is the specific policy setting that was modified. Microsoft uses inconsistent value formats across settings, some use keyword strings True/False while others use Enabled/Disabled. The rule accounts for both formats using OR logic: (true or "Enabled") and (false or "Disabled").

Selected scenarios

Each OR branch in the query targets a specific setting transition from disabled → enabled:

Setting	What it controls	Threat relevance
ShareWithGuests	Guest/external sharing on a site	Enables data sharing with external accounts
ShareUsingAnonymousLinks	Anonymous "Anyone" link sharing	Creates unauthenticated access to content
IsPublic	Site/group public visibility	Exposes private site content broadly
AllowGuestUser	Guest user access to the site	Permits external guest accounts
AllowFederatedUsers	Federated (external org) user access	Opens cross-tenant access
AllowTeamsConsumer	Teams personal account access	Permits unmanaged consumer accounts

These settings were identified via _field_caps against live M365 audit data and validated with terms aggregations filtered to SharingPolicyChanged events. The OldValue check ensures the rule only fires on actual weakening transitions (disabled -> enabled), not idempotent re-applications or strengthening changes.

How To Test

Query can be used in the TRADE stack.

Checklist

• Added a label for the type of pr: Rule: New
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.