« Microsoft Entra ID Session Reuse with Suspicious Graph Access Microsoft Exchange Server UM Spawning Suspicious Processes »
Elastic Docs ›Elastic Security Solution [8.18] ›Detections and alerts ›Prebuilt rule reference

Microsoft Entra ID SharePoint Access for User Principal via Auth Broker

edit
A newer version is available. Check out the latest documentation.

Microsoft Entra ID SharePoint Access for User Principal via Auth Broker

edit

This rule detects non-interactive authentication activity against SharePoint Online (Office 365 SharePoint Online) by a user principal via the Microsoft Authentication Broker application. The session leverages a refresh token or Primary Refresh Token (PRT) without interactive sign-in, often used in OAuth phishing or token replay scenarios.

Rule type: new_terms

Rule indices:

  • logs-azure.signinlogs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Use Case: Identity and Access Audit
  • Tactic: Collection
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Sign-in Logs
  • Resources: Investigation Guide

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Microsoft Entra ID SharePoint Access for User Principal via Auth Broker

This rule identifies non-interactive sign-ins to SharePoint Online via the Microsoft Authentication Broker application using a refresh token or Primary Refresh Token (PRT). This type of activity may indicate token replay attacks, OAuth abuse, or automated access from previously consented apps or stolen sessions.

This is a New Terms rule that detects the first occurrence of a user principal name accessing SharePoint Online via the Microsoft Authentication Broker application in the last 14 days.

Possible Investigation Steps:

  • azure.signinlogs.properties.user_principal_name: Identify the user involved. Investigate whether this user typically accesses SharePoint or if this is an anomaly.
  • azure.signinlogs.properties.app_display_name: Verify the application used (e.g., Authentication Broker). Determine if the app is expected for SharePoint access in your environment.
  • azure.signinlogs.properties.resource_display_name: Review the resource being accessed. SharePoint activity should be aligned with job roles or historical usage.
  • azure.signinlogs.properties.incoming_token_type: Indicates the token type used. Look for refreshToken or primaryRefreshToken, which may point to token replay or silent access.
  • azure.signinlogs.properties.is_interactive: If false, indicates the sign-in was non-interactive. Correlate with recent sign-ins to understand if a prior session may have been reused.
  • user_agent.original: Analyze the user agent string for automation indicators (e.g., scripts, unusual clients). Compare with what’s typical for the user or device.
  • source.ip: Check the originating IP address. Investigate if the IP is associated with data centers, VPNs, anonymizers, or is geographically unusual for the user.
  • source.geo.*: Evaluate sign-in location details. Determine if the sign-in location aligns with expected travel or usage behavior.
  • azure.signinlogs.properties.applied_conditional_access_policies: Review whether Conditional Access policies were triggered or bypassed. Investigate if required controls (like MFA) were applied.
  • azure.signinlogs.properties.authentication_processing_details: Review any details about the authentication, such as token type or scopes. This may indicate delegated access or automation patterns.

False Positive Analysis

  • Certain MDM or mobile app scenarios may use refresh tokens legitimately via brokered apps.
  • Automated processes using authorized, scripted clients could trigger this activity, especially in developer or operations environments.
  • If Conditional Access policies are configured in “report-only” mode or exempted for trusted apps, activity may appear unusual but be authorized.

Response and Remediation

  • If activity appears unauthorized:
  • Investigate and revoke active sessions or refresh tokens.
  • Notify the user and validate expected activity.
  • Review and audit app consent permissions and remove unused or high-risk delegated access.
  • Harden Conditional Access policies to limit non-interactive access to sensitive resources.
  • Monitor for repeated use of the same user agent, IP, or token type across other users to identify broader campaigns.
  • Consider alerting on unusual patterns in sign-in frequency, geography, and application usage for SharePoint and other key services.

Setup

edit

Required Microsoft Entra ID Sign-In Logs

To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.

Rule query

edit
event.dataset: "azure.signinlogs"
    and azure.signinlogs.properties.app_id: "29d9ed98-a469-4536-ade2-f981bc1d605e"
    and azure.signinlogs.properties.resource_id: "00000003-0000-0ff1-ce00-000000000000"
    and azure.signinlogs.identity: *
    and azure.signinlogs.properties.user_principal_name: *
    and azure.signinlogs.properties.incoming_token_type: ("refreshToken" or "primaryRefreshToken")
    and azure.signinlogs.properties.is_interactive: false

Framework: MITRE ATT&CKTM

« Microsoft Entra ID Session Reuse with Suspicious Graph Access Microsoft Exchange Server UM Spawning Suspicious Processes »