WINDOWS

DETECTION
PLAYBOOK: 20
ACTIONABLE
ALERT
SCENARIOS WITH
SIMULATIONS
BY IZZMIER IZZUDDIN
SCENARIO 1: SUSPICIOUS LOGIN FROM MULTIPLE GEOGRAPHIES IN A
SHORT TIMEFRAME

Impossible Travel Sign-In — Potential Compromised Account

This scenario detects when a user logs into their Microsoft 365 account (with E5 license)
from two geographically distant locations within a short period, making normal travel
between them impossible. This behaviour may indicate credential compromise and
session hijacking.

MITRE ATT&CK Mapping:

• T1078 – Valid Accounts

• T1550.001 – Application Access Token
• T1110.001 – Password Guessing (if brute-force observed)
• T1036 – Masquerading (if using legitimate accounts from unusual IPs)

Data Source:

• Azure AD Sign-in Logs (Microsoft Entra ID / Defender for Cloud Apps)

• Conditional Access Policies
• Identity Protection Risk Events

Log Data:

AzureAD sign-in logs:

Timesta UserPrincipalN Locat IPAddres Devic ResuAp Authenticatio Risk

mp ame ion s e lt p nMethod Leve
(UTC) Us l
ed
2025- azrul.rahman Kuala 175.140. WIN1 Succ O3 MFA Medi
06- @corp.com Lump 22.14 0- ess 65 um
30T08:1 ur, LAPT
2:45Z MY OP
2025- azrul.rahman Frank 185.32.1 Unkn Succ O3 Password High
06- @corp.com furt, 55.100 own ess 65 Only
30T08:1 DE
8:12Z

Alert Logic / Rule:

Detection Name: Impossible Travel Sign-in

Trigger Condition:
 1. Two successful logins for the same user within < 30 minutes.
2. Login IPs/geolocations are > 5000 km apart.
3. One or both authentications with weak/no MFA.
4. Unusual device fingerprinting (optional enhancement).

Query Example (KQL for Azure Sentinel):

let time_window = 30m;

SigninLogs
| where ResultType == 0
| project UserPrincipalName, IPAddress, Location, DeviceDetail,
AuthenticationRequirement, TimeGenerated
| join kind=inner (
SigninLogs
| where ResultType == 0
| project UserPrincipalName, IPAddress, Location, DeviceDetail,
AuthenticationRequirement, TimeGenerated
) on UserPrincipalName
| where abs(datetime_diff("minute", TimeGenerated1, TimeGenerated2)) < 30
| where Location1 != Location2
| extend DistanceKm = geo_distance_approx(Location1, Location2)
| where DistanceKm > 5000

Alert Output:

Title: Suspicious Login: Impossible Travel Detected

Severity: High
User: [email protected]
Description: Two successful login events occurred for the same user from Kuala Lumpur,
Malaysia and Frankfurt, Germany within 6 minutes, a distance of 9,900km. This may
indicate credential theft or session hijacking.

Analyst Investigation Steps:

1. Verify User Activity:

o Call or message the user to confirm if they performed both logins.
o Check their device IP address and location history.
2. Review Sign-in Logs:
o Filter sign-ins for the user in the last 24 hours.
o Look for other anomalous IPs or user agents.
3. Review Conditional Access Policies:
o Was the second login blocked or allowed?
o Was MFA enforced?
4. Check for Lateral Movement:
 o Has this identity accessed other resources unusually?
o Any PowerShell or Graph API usage post-login?
5. Threat Intelligence:
o Check the IP 185.32.155.100 in VirusTotal or threat feeds.
6. User Device Inventory:
o Was the login from a known corporate-managed device?
o Any device enrolled in Intune or Defender for Endpoint?

Recommendation:

• Immediate:
o Lock or disable the account.
o Invalidate all active sessions via Entra ID.
o Force password reset (ensure MFA is re-enforced).
• Medium-Term:
o Enforce stricter Conditional Access Policies.
o Audit all users for similar impossible travel patterns.
o Enable real-time risk-based policies (Microsoft Identity Protection).
• Long-Term:
o Consider integrating with Defender for Identity and Defender for Endpoint for
cross-signal correlation.
o Educate users on phishing and credential hygiene.
SCENARIO 2: SUSPICIOUS OAUTH APPLICATION CONSENT GRANT BY
USER

Malicious OAuth Application Consent — Token Theft via Rogue App

This scenario simulates an attacker sending a phishing link that leads the victim to grant
consent to a rogue OAuth2 application. Once the user accepts, the app gains persistent
access to Microsoft 365 resources like mail, files and calendars using access tokens
bypassing MFA. This tactic has been used in real-world campaigns (e.g., consent phishing).

MITRE ATT&CK Mapping:

• T1528 – Steal Application Access Token

• T1550.001 – Application Access Token
• T1078 – Valid Accounts
• T1566.002 – Spearphishing via Link

Data Source:

• Azure AD Audit Logs

• Microsoft Entra ID Logs
• Microsoft Defender for Cloud Apps (MDCA) OAuth Apps Discovery

Log Data:

Azure AD Audit Logs:

Timesta Activity UserPrincipalNa App DisplayPermissio Statu IP

mp (UTC) Display me Name ns s Address
Name Granted
2025-06- Consen safwan.omar@co DocumentVi Mail.Read Succ 196.23.88
30T10:04 t to rp.com ewer Plus , ess .112
:21Z applica Files.Rea
tion d.All,
offline_ac
cess
2025-06- User safwan.omar@co Office365 - Succ 175.142.5
30T10:05 login rp.com Web ess 5.17
:10Z

The rogue app DocumentViewer Plus requested extensive read permissions typically not
required by document viewers.

Alert Logic / Rule:

Detection Name: Suspicious OAuth Consent Grant
Trigger Condition:

1. User grants consent to a new app not previously seen in the tenant.
2. App requests high-risk permissions (e.g., Mail.Read, Files.Read.All, offline_access).
3. User is not an admin (indicating self-granted consent).
4. IP reputation of consent-granting activity is questionable (optional enhancement).

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Consent to application"
| where Result == "success"
| where isnotempty(AppDisplayName)
| extend ConsentPermissions =
tostring(TargetResources[0].ModifiedProperties[?displayName=="Consent
Action"].NewValue)
| where ConsentPermissions has_any ("Mail.Read", "Files.Read.All", "offline_access")
| summarize FirstSeen=min(TimeGenerated),
Users=make_set(InitiatedBy.user.userPrincipalName) by AppDisplayName

Alert Output:

Title: Suspicious OAuth Consent Granted — Potential Token Abuse

Severity: High
User: [email protected]
Description: A non-admin user has granted access to a new third-party OAuth2 application
DocumentViewer Plus, which requested sensitive read scopes including Mail.Read,
Files.Read.All and offline_access. This may indicate phishing or token abuse.

Analyst Investigation Steps:

1. Review Application:
o Was this app known or verified in the organisation?
o Is it published by a trusted vendor?
2. Check User Context:
o Did the user click on a phishing email or suspicious link?
o Is the IP 196.23.88.112 associated with past alerts or threat intel?
3. Cross-Check Token Usage:
o Check Microsoft Defender for Cloud Apps (MDCA) or Unified Audit Logs to
see what the app accessed post-consent.
4. Investigate User Activity:
o Has the user sent any suspicious emails after the grant?
o Are there mass file downloads or mail forwarding rules?
 5. TI/OSINT:
o Investigate app name DocumentViewer Plus across community sources
(GitHub, VirusTotal, AbuseIPDB).

Recommendation:

• Immediate:
o Revoke app permissions via Microsoft Entra Admin Center.
o Notify the user and reset their session/token.
o Block the app across the tenant using Admin Consent Policies.
• Medium-Term:
o Enable consent workflow requiring admin approval for third-party apps.
o Audit all OAuth applications installed in the past 30 days.
• Long-Term:
o Train users to identify consent phishing.
o Integrate with Defender for Cloud Apps to enforce app risk scoring and app
governance.
SCENARIO 3: IMPOSSIBLE DEVICE — SIGN-IN FROM UNKNOWN OR
UNMANAGED DEVICE AFTER LONG CORPORATE INACTIVITY

Dormant Account Reactivation from Unmanaged Device

This scenario identifies when a previously dormant or inactive user account suddenly
becomes active and logs in from a non-compliant, unmanaged or unknown device. This is
commonly associated with compromised accounts that were not in use but had weak or
leaked credentials.

MITRE ATT&CK Mapping:

• T1078 – Valid Accounts

• T1531 – Account Access Removal (if account was previously disabled)
• T1556 – Modify Authentication Process
• T1550.001 – Application Access Token

Data Source:

• Microsoft Entra ID (Azure AD) Sign-in Logs

• Microsoft Intune Device Compliance
• Microsoft Defender for Endpoint (if integrated)
• Audit Logs (Account Enablement)

Log Data:

Timest Activi UserPrincipa Devic Man Device IP Loca App Res

amp ty lName e aged Compl Address tion Use ult
(UTC) Displ Nam Devi iance d
ay e ce
Name
2025- User haziq.khairi - - - 10.10.1. HQ Suc
06- acco @corp.com 10 Adm cess
30T04: unt in
12:07Z enabl Port
ed al
2025- Intera haziq.khairi DESK No Non- 102.22. Nige Offic Suc
06- ctive @corp.com TOP- compli 31.201 ria e cess
30T04: Sign- 555X ant 365
30:14Z in

Alert Logic / Rule:

Detection Name: Dormant Account Access from Unmanaged Device
Trigger Conditions:

1. Account was re-enabled or re-used after >60 days of inactivity.

2. First login event occurs within <1 hour of enablement (suspicious).
3. Device is unmanaged or non-compliant.
4. Device location/IP is not normal for the organisation.

KQL Query Example (Sentinel):

let DormantUsers = AuditLogs

| where ActivityDisplayName == "User account enabled"
| extend user = TargetResources[0].userPrincipalName, EnableTime = TimeGenerated;
SigninLogs
| where ResultType == 0
| extend user = UserPrincipalName
| join kind=inner (DormantUsers) on user
| where TimeGenerated < EnableTime + 1h
| where isManaged != true or isCompliant != true
| project TimeGenerated, user, IPAddress, Location, DeviceDetail, isManaged, isCompliant

Alert Output:

Title: Reactivated Dormant Account Accessed from Non-Compliant Device

Severity: High
User: [email protected]
Description: User account was enabled and accessed within 20 minutes from an
unmanaged, non-compliant device located in Nigeria. This device is not registered with
Microsoft Intune or Defender for Endpoint and such access is highly suspicious.

Analyst Investigation Steps:

1. Account Verification:
o Was this account supposed to be reactivated?
o Was the reactivation scheduled or requested?
2. Device Inventory Check:
o Is DESKTOP-555X part of corporate inventory or known test environments?
o Was this device ever registered in Intune?
3. Network & Location Context:
o Does the IP 102.22.31.201 appear in historical corporate access logs?
o Any previous logins from Nigeria in the organisation?
4. Lateral Movement Detection:
o Has this identity accessed sensitive SharePoint, Exchange or Teams
resources?
 o Any spikes in data access/download?
5. Token Usage & API Calls:
o Was Graph API or OneDrive Sync initiated?

Recommendation:

• Immediate:
o Re-disable the account.
o Invalidate sessions and revoke tokens.
o Block the IP address temporarily via Conditional Access or Firewall.
• Medium-Term:
o Review all dormant accounts and implement Conditional Access for
reactivation flow.
o Enforce MFA immediately upon account enablement.
• Long-Term:
o Implement Identity Protection Risk Policies for dormant accounts.
o Ensure device registration and compliance is enforced before sign-in.
SCENARIO 4: CREATION OF MAIL FORWARDING RULE TO EXTERNAL
ADDRESS — POTENTIAL DATA EXFILTRATION

Suspicious Inbox Rule — Auto Forward to External Email

Description:

Attackers who compromise Microsoft 365 accounts often set up mailbox rules to forward
all incoming emails to external addresses. This tactic is used for espionage, business
email compromise (BEC) or monitoring sensitive communications over time.

MITRE ATT&CK Mapping:

• T1114.003 – Email Collection: Email Forwarding Rule

• T1087 – Account Discovery
• T1078 – Valid Accounts
• T1566.001 – Phishing via Email

Data Source:

• Microsoft 365 Audit Logs (Exchange Mailbox Activities)

• Microsoft Defender for Office 365
• Unified Audit Log via Microsoft Purview
• Defender for Cloud Apps (MCAS)

Log Data:

Timesta UserPrincipalN Activi Rule Actio Forward To Client Resu

mp ame ty Name n IP lt
(UTC) Nam
e
2025- hafizah.zulkifli New- auto_fw Forwa hacker.outlook 93.12.4 Succ
06- @corp.com Inbox d_ext rdTo @mail.com 4.210 ess
30T03:4 Rule
4:11Z
2025- hafizah.zulkifli Send - - - 93.12.4 Succ
06- @corp.com Email 4.210 ess
30T03:4 (Test)
5:08Z

Alert Logic / Rule:

Detection Name: External Mail Forwarding Rule Created
Trigger Conditions:

1. New inbox rule created using ForwardTo, RedirectTo or ForwardAsAttachment.

2. Destination address is outside of the organisation’s domain.
3. Client IP is suspicious or previously unseen.

KQL Query Example (Sentinel):

OfficeActivity
| where RecordType == "ExchangeMailboxAudit"
| where Operation == "New-InboxRule"
| extend RuleAction = parse_json(Parameters)[0].Value
| where RuleAction has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachment")
| extend ForwardAddress = tostring(parse_json(Parameters)[1].Value)
| where not(ForwardAddress endswith "@corp.com")
| project TimeGenerated, UserId, Operation, RuleAction, ForwardAddress, ClientIP

Alert Output:

Title: Suspicious Inbox Rule Created — External Forwarding

Severity: High
User: [email protected]
Description: A new inbox rule named auto_fwd_ext was created to forward emails to
[email protected]. This action may indicate account compromise or data
exfiltration setup.

Analyst Investigation Steps:

1. Verify with User:

o Did the user configure this rule intentionally?
o Were they recently targeted by phishing?
2. Review Rule Details:
o What conditions or keywords triggered the forwarding rule?
o Were specific sender addresses targeted (e.g., finance@, ceo@)?
3. Email Activity Review:
o Check emails sent or received in the last 48 hours.
o Identify whether sensitive data may have been forwarded.
4. Client IP Context:
o Investigate the IP 93.12.44.210 is it from an expected region?
o Correlate with prior login attempts.
5. Audit Other Rules:
o Check for additional mailbox rules (auto-delete, move to archive, etc.).
Recommendation:

• Immediate:
o Remove the malicious inbox rule.
o Reset user password and force sign-out across all sessions.
o Alert user and suspend outbound mail flow temporarily if necessary.
• Medium-Term:
o Review audit logs for all users with forwarding rules.
o Enable alerting via Defender for Office 365 for all rule creation events.
• Long-Term:
o Block external forwarding using Exchange Transport Rules (ETR).
o Require approval for any new inbox rules with external targets.
SCENARIO 5: ELEVATION OF PRIVILEGES — USER ADDED TO GLOBAL
ADMIN ROLE WITHOUT CHANGE REQUEST

Unapproved Privilege Escalation via Directory Role Assignment

An attacker who gains access to a standard user account may attempt to add themselves
or another compromised identity to high-privilege Azure AD roles (e.g., Global
Administrator). This scenario detects unauthorised elevation of privileges through directory
role changes.

MITRE ATT&CK Mapping:

• T1078.004 – Valid Accounts: Cloud Accounts

• T1098 – Account Manipulation
• T1070.006 – Indicator Removal on Host: Timestomp (if backdating logs)
• T1059 – Command and Scripting Interpreter (if done via Graph API/PowerShell)

Data Source:

• Microsoft Entra ID Audit Logs

• Microsoft Defender for Identity (if integrated)
• Azure AD Role Assignments
• Privileged Identity Management (PIM) Alerts

Log Data:

Timesta Activi Initiated By Target User Role Source IP Statu

mp (UTC) ty Added s
Displ
ay
Nam
e
2025-06- Add faiz.musa@corp. izzuddin.idris@c Global 104.20.33 Succ
30T01:23 mem com orp.com Administ .100 ess
:45Z ber to rator
role
2025-06- Sign- izzuddin.idris@c - - 104.20.33 Succ
30T01:25 in orp.com .100 ess
:01Z

No approved change request or PIM activation was recorded for this assignment. The
initiating user was not previously authorised to manage roles.

Alert Logic / Rule:

Detection Name: Role Assignment to Global Admin Outside Change Window
Trigger Conditions:

1. Any role assignment where RoleName == Global Administrator.

2. Initiator is not part of Privileged Identity Management (PIM) process.
3. No associated ServiceNow/JIRA/ITSM change request (if integrated).
4. IP or geolocation of role change is suspicious or new.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Add member to role"
| where tostring(TargetResources[0].displayName) == "Global Administrator"
| extend Initiator = InitiatedBy.user.userPrincipalName
| extend TargetUser = tostring(TargetResources[1].userPrincipalName)
| extend IPAddress = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, Initiator, TargetUser, IPAddress, Status
| where Status == "Success"

Alert Output:

Title: Unapproved Role Assignment — Global Administrator

Severity: Critical
Initiator: [email protected]
Target User: [email protected]
Description: A user with no recent privileged activity has assigned the Global Administrator
role to another account. This action occurred without PIM approval and originated from an
IP 104.20.33.100 not previously seen in the environment.

Analyst Investigation Steps:

1. Identity & Role Validation:

o Was [email protected] authorised to perform role assignments?
o Is the added user ([email protected]) a legitimate administrator?
2. Change Management Check:
o Any open or closed ITSM ticket related to this role change?
o Is there a PIM log approving this change?
3. IP & Geo Verification:
o Is IP 104.20.33.100 associated with previous administrator activity?
o Correlate with other sign-ins or threat alerts.
4. Logon & Access Pattern Review:
o Review what [email protected] accessed post-assignment.
o Check for critical resource access (Azure subscriptions, SharePoint,
Defender Console).
 5. Correlate with Other Activity:
o Were other roles modified? Were any conditional access policies changed?
o Was MFA method updated or removed?

Recommendation:

• Immediate:
o Remove Global Administrator role from [email protected].
o Investigate and possibly suspend [email protected].
o Trigger emergency change freeze if suspicious activity is ongoing.
• Medium-Term:
o Audit all role assignments in the last 30 days.
o Enforce PIM across all privileged roles with approval and justification.
• Long-Term:
o Block direct assignment of critical roles outside PIM.
o Enable Defender for Identity to monitor role abuse signals.
o Implement real-time alerting for all role change events.
Scenario 6: Multiple Failed MFA Attempts Followed By Successful Login —
Potential Brute Force Or MFA Fatigue Attack

MFA Fatigue or Brute Force Attempt Leading to Account Access

This scenario simulates an attacker trying to repeatedly trigger MFA push notifications
(e.g., Microsoft Authenticator) until the victim accidentally approves it or the attacker
brute-forces credentials and successfully bypasses MFA due to weak configuration (like
allowing fallback to SMS or call).

MITRE ATT&CK Mapping:

• T1110.001 – Brute Force: Password Guessing

• T1110.003 – MFA Request Generation (MFA Fatigue)
• T1078 – Valid Accounts
• T1556 – Modify Authentication Process (optional if MFA methods are tampered)

Data Source:

• Azure AD Sign-in Logs

• Microsoft Identity Protection Logs
• Defender for Cloud Apps Alerts
• Entra Conditional Access Insights
• Authentication Methods Activity Logs

Log Data:

Timestamp UserPrincipalName Result MFA Authenticati IP Locatio

(UTC) Requir on Method Address n
ed
2025-06- nora.azman@corp. Failed Yes MFA Push 203.12.4 Unkno
30T02:05:0 com 4.1 wn
0Z
2025-06- nora.azman@corp. Failed Yes MFA Push 203.12.4 Unkno
30T02:05:3 com 4.1 wn
0Z
2025-06- nora.azman@corp. Failed Yes MFA Push 203.12.4 Unkno
30T02:06:0 com 4.1 wn
1Z
2025-06- nora.azman@corp. Succe Yes MFA Push 203.12.4 Unkno
30T02:06:3 com ss Approved 4.1 wn
4Z

Alert Logic / Rule:

Detection Name: MFA Fatigue or MFA Brute Force Success
Trigger Conditions:

1. ≥3 failed sign-in attempts within 2–5 minutes with MFA required.

2. All from the same IP or unknown source.
3. Followed by a successful MFA login within <1 minute.
4. Optional: Repeated MFA push method used (push fatigue pattern).

KQL Query Example (Sentinel):

let MFAFailures = SigninLogs

| where ResultType != 0 and AuthenticationRequirement == "multiFactorAuthentication"
| summarize CountFailures = count(), LatestFailure = max(TimeGenerated)
by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where CountFailures >= 3;

let MFASuccess = SigninLogs

| where ResultType == 0 and AuthenticationRequirement == "multiFactorAuthentication";

MFAFailures
| join kind=inner (
MFASuccess
| project UserPrincipalName, IPAddress, TimeGenerated, AuthenticationDetails
) on UserPrincipalName, IPAddress
| where TimeGenerated between (LatestFailure .. LatestFailure + 5m)
| project UserPrincipalName, IPAddress, CountFailures, TimeGenerated,
AuthenticationDetails

Alert Output:

Title: Potential MFA Fatigue Attack Leading to Account Access

Severity: High
User: [email protected]
Description: Multiple failed sign-in attempts with MFA from the same IP (203.12.44.1) were
followed by a successful sign-in within 1 minute using push-based MFA. This may indicate
an MFA fatigue attack or forced MFA approval by the user.

Analyst Investigation Steps:

1. Validate User Intent:

o Contact user and ask if they approved the sign-in.
o Was the MFA prompt expected or were they spammed with requests?
2. Review IP and Location:
o Is 203.12.44.1 associated with any known office network or VPN?
 o Has this IP been used before by the user?
3. Check for Signs of Brute Force:
o Review the sign-in logs for repeated attempts on other accounts from same
IP.
o Any password spray or login storm patterns?
4. Authentication Method Review:
o What MFA method was used push, SMS, phone call?
o Was fallback used after push failure (e.g., SMS override)?
5. Threat Intel:
o Check IP reputation and correlate with known attack infrastructure.

Recommendation:

• Immediate:
o Revoke session tokens for [email protected].
o Reset password and enforce MFA re-registration.
o Block IP 203.12.44.1 temporarily via Conditional Access.
• Medium-Term:
o Disable push-only MFA (enable number matching or OTP).
o Review user group with similar configurations.
• Long-Term:
o Enforce sign-in risk policies via Microsoft Identity Protection.
o Monitor for excessive MFA prompts across the tenant.
SCENARIO 7: UNUSUAL NUMBER OF REPORT MESSAGE ACTIONS —
POSSIBLE PHISHING SIMULATION ABUSE OR MALICIOUS REPORTING
PATTERN

Excessive Message Reporting by Single User — Potential Abuse of Report Phishing

Feature

This scenario detects when a user reports an abnormal number of emails as phishing or
junk in a short period using the “Report Message” add-in or Defender for Office 365. It may
indicate one of the following:

• A user unknowingly participating in a phishing simulation but overreporting

legitimate mail.
• An insider trying to hide real emails from being read.
• A compromised account triggering mass reports to disrupt operations or
impersonate false positives.

MITRE ATT&CK Mapping:

• T1565.001 – Stored Data Manipulation: Email Content or Status

• T1585.002 – Abuse of Email Reporting Systems
• T1078 – Valid Accounts
• T1531 – Account Misuse or Signal Manipulation

Data Source:

• Microsoft Defender for Office 365 (Threat Explorer / Submissions)

• Microsoft Purview Audit Logs
• Unified Audit Logs (Report Message Activity)
• Microsoft Defender for Cloud Apps (MCAS)

Log Data:

Timestam UserPrincipalNam Action Message Report Report IP Address

p (UTC) e Type Subject ed As Tool
Used
2025-06- amir.nazim@corp Report "Project Phishin Outloo 124.188.77
30T16:31: .com Messa Kickoff – g k Add- .32
12Z ge CEO" in
2025-06- amir.nazim@corp Report "Team Phishin Outloo 124.188.77
30T16:31: .com Messa Weekly Sync g k Add- .32
44Z ge Agenda" in
 2025-06- amir.nazim@corp Report "Payroll Junk Report 124.188.77
30T16:32: .com Messa Team Messa .32
08Z ge Announcem ge
ent" Button
2025-06- amir.nazim@corp Report "VPN Access Phishin Outloo 124.188.77
30T16:32: .com Messa Instructions" g k Add- .32
30Z ge in

10+ messages reported as phishing or junk within 3 minutes, all from corporate senders.
User has no history of high-volume reporting.

Alert Logic / Rule:

Detection Name: Abnormal Spike in Report Message Submissions by Single User

Trigger Conditions:

1. ≥10 report message actions by same user within 5 minutes.

2. Majority of messages are from internal senders.
3. No confirmed phishing in those messages.
4. Optional: IP address or device is new or untrusted.

KQL Query Example (Sentinel):

OfficeActivity
| where Operation == "ReportMessage"
| summarize Reports = count(), TimeRange = max(TimeGenerated) - min(TimeGenerated)
by UserId, ClientIP
| where Reports >= 10 and TimeRange < 5m

Alert Output:

Title: Excessive Message Reporting by User — Possible Abuse or Anomaly

Severity: Medium
User: [email protected]
Description: The user reported 10+ emails as phishing or junk in less than 3 minutes using
Outlook's reporting tool. Most reported emails were internal communications. Behaviour is
unusual and requires validation.

Analyst Investigation Steps:

1. Verify User Intent:

o Is the user participating in a phishing simulation or awareness exercise?
o Did the user report by mistake or automation?
2. Review Message Content:
 o Are the reported messages legitimate or simulated phishing?
o Were any of them confirmed threats?
3. Check Device and Location:
o Is the reporting IP address trusted?
o Is this from a managed corporate device?
4. Assess Past User Behaviour:
o Has the user reported similar volumes in the past?
o Any recent alerts tied to this account?

Recommendation:

• Immediate:
o Contact the user and confirm awareness of the reports.
o Flag messages to avoid unnecessary escalation or automated blocking.
• Medium-Term:
o Correlate reporting activity with phishing simulations or compromised
behavior.
o Add alerting thresholds for abuse of “Report Message” functionality.
• Long-Term:
o Train users on when and how to report suspicious emails.
o Use MCAS or Sentinel to correlate anomalous reporting patterns tenant-
wide.
SCENARIO 8: SUSPICIOUS EMAIL SENT FROM USER MAILBOX TO
EXTERNAL RECIPIENTS — POSSIBLE ACCOUNT TAKEOVER (ATO)

Compromised Account Sending Malicious or Unexpected Emails to External

Recipients

This scenario detects a potentially compromised mailbox being used to send emails to
multiple external recipients especially if the user is not in a role that typically
communicates with external parties. It may involve phishing, data exfiltration or business
email compromise (BEC).

MITRE ATT&CK Mapping:

• T1078 – Valid Accounts

• T1566.001 – Phishing via Email
• T1114 – Email Collection
• T1585.002 – Abuse of Compromised Email Account

Data Source:

• Microsoft 365 Audit Logs

• Defender for Office 365 Alerts
• Exchange Online Transport Logs
• Microsoft Defender for Cloud Apps (MDCA)

Log Data:

Timesta UserPrincipalN Activit Subj Recipient(s) IP Attach Resu

mp ame y Type ect Addres ment lt
(UTC) s
2025- rahman.yusof@ SendE Invoi tanaka.yuki@g 102.66. invoice. Succ
06- corp.com mail ce mail.com; 88.55 zip ess
30T07:1 for [email protected]
8:10Z Pay
ment
(Urge
nt)
2025- rahman.yusof@ SendE RE: michael.l@xyz 102.66. timelin Succ
06- corp.com mail Proje group.net 88.55 e.doc ess
30T07:1 ct
9:22Z Timel
ine
Both emails contained zipped attachments, sent within 2 minutes to multiple unrelated
external domains. IP address and communication pattern are new for this user.

Alert Logic / Rule:

Detection Name: Suspicious External Email Burst from Internal Mailbox

Trigger Conditions:

1. Internal user sends ≥2 emails to unrelated external recipients within <5 minutes.
2. Subject contains keywords like “Invoice”, “Urgent”, “Payment” or “Timeline”.
3. Attachment included (especially ZIP, EXE, DOC, etc.).
4. New sending pattern (never sent externally before or IP address is new).

KQL Query Example (Sentinel):

EmailEvents
| where SenderFromDomain =~ "corp.com"
| where RecipientEmailAddress !endswith "@corp.com"
| where AttachmentCount > 0
| where Subject has_any("invoice", "payment", "urgent", "timeline")
| summarize CountSent = count(), Recipients=make_set(RecipientEmailAddress),
StartTime=min(TimeGenerated), EndTime=max(TimeGenerated)
by SenderFromAddress, ClientIP
| where CountSent >= 2 and EndTime - StartTime < 5m

Alert Output:

Title: Suspicious Email Activity from Internal Mailbox — Potential ATO

Severity: High
User: [email protected]
Description: Multiple emails with suspicious financial subjects and attachments were sent
externally in a short timeframe. This behaviour, combined with a new IP 102.66.88.55,
indicates potential account compromise.

Analyst Investigation Steps:

1. User Verification:
o Confirm with the user whether they sent those emails.
o Were they working from a new location or under delegation?
2. Review Message Content:
o Download and scan the attachments (e.g., invoice.zip) for malware or
macros.
o Review the email headers and language used.
3. Login Pattern Check:
 o Was there a prior unusual login (MFA fatigue, impossible travel, etc.)?
o Was this IP used before by the user?
4. External Recipient Analysis:
o Are the recipients known clients or completely random addresses?
o Correlate with any reports of phishing received externally.
5. Threat Intel Check:
o Look up 102.66.88.55 for known malicious infrastructure.

Recommendation:

• Immediate:
o Block user from sending external emails (via Transport Rule or mailbox
restriction).
o Revoke session tokens and force sign-out.
o Reset password and review MFA settings.
• Medium-Term:
o Notify recipients if malicious content was confirmed.
o Review all mailbox rules and recent login sessions.
• Long-Term:
o Enable outbound DLP policies and MDCA anomaly detection.
o Implement email-sending rate limits and anomalous volume alerts.
Scenario 9: Legacy Authentication Attempt on Account with Modern Auth
Enforced — Possible Bypass Attempt

Potential Recon or Brute Force

Despite modern authentication being enforced across Microsoft 365, attackers often
attempt to exploit older legacy protocols (e.g., IMAP, POP3, SMTP AUTH) to brute-force
credentials or bypass MFA. These protocols don’t support modern auth and should be
disabled. Detection of such attempts, even when blocked, is critical for early warning.

MITRE ATT&CK Mapping:

• T1110 – Brute Force

• T1078 – Valid Accounts
• T1040 – Network Protocol Exploitation
• T1556 – Modify Authentication Process

Data Source:

• Azure AD Sign-in Logs

• Conditional Access Logs
• Microsoft Defender for Cloud Apps
• Microsoft 365 Service Health Alerts (optional)

Log Data:

Timestam UserPrincipalNa Resu Clie Authentica IP Address Device Locati

p (UTC) me lt nt tion on
App Protocol
Use
d
2025-06- nur.adilah@cor Failu Othe IMAP 198.51.10 Unkno Russi
30T05:12: p.com re r 0.77 wn a
45Z clien
ts
2025-06- nur.adilah@cor Failu Othe POP3 198.51.10 Unkno Russi
30T05:14: p.com re r 0.77 wn a
00Z clien
ts
2025-06- nur.adilah@cor Failu Othe SMTP 198.51.10 Unkno Russi
30T05:15: p.com re r AUTH 0.77 wn a
10Z clien
ts
The IP and authentication protocols indicate an attacker probing the account via
deprecated protocols.

Alert Logic / Rule:

Detection Name: Legacy Authentication Attempt on Modern-Only Account

Trigger Conditions:

1. Authentication attempt using IMAP, POP or SMTP AUTH.

2. Result is failure due to modern auth requirement or Conditional Access policy.
3. IP address is from an unknown or high-risk geolocation.
4. Device is unknown or unmanaged.

KQL Query Example (Sentinel):

SigninLogs
| where ResultType != 0
| where ClientAppUsed in ("IMAP", "POP", "SMTP")
| where AuthenticationRequirement == "singleFactorAuthentication"
| project TimeGenerated, UserPrincipalName, ClientAppUsed, IPAddress, Location,
DeviceDetail, ResultDescription

Alert Output:

Title: Legacy Auth Attempt Blocked — Possible Recon or Brute Force

Severity: Medium
User: [email protected]
Description: Multiple sign-in attempts using deprecated protocols (IMAP, POP3, SMTP
AUTH) were blocked by Conditional Access policy. These attempts originated from a
foreign IP (198.51.100.77) and may indicate password spraying or reconnaissance.

Analyst Investigation Steps:

1. Confirm Modern Auth Enforcement:

o Is modern authentication enforced for this user or globally?
o Are legacy protocols disabled in the Exchange Online admin center?
2. Review Account Usage:
o Has the user ever accessed mail using legacy clients or mobile apps?
o Was the user active during the time of attempt?
3. Check IP and Source Reputation:
o Look up IP 198.51.100.77 on VirusTotal or AbuseIPDB.
o Was this IP used for other login attempts across the tenant?
4. Cross-Reference with Conditional Access Logs:
o Was the sign-in explicitly blocked due to policy?
 o Are similar attempts happening for other users?
5. Consider Tenant-Wide Trends:
o Any spike in failed logins from specific geolocations or apps?

Recommendation:

• Immediate:
o Review logs for similar attempts on other identities.
o Add IP to geo-block policy or detection watchlist.
• Medium-Term:
o Ensure Exchange Online has IMAP, POP and SMTP AUTH disabled tenant-
wide.
o Audit Conditional Access policies to ensure legacy block enforcement.
• Long-Term:
o Educate users on modern client requirements.
o Enable Defender for Office 365 anomaly alerts for brute force patterns.
SCENARIO 10: USER DOWNLOADS POWER BI DATASET MARKED AS
CONFIDENTIAL — POTENTIAL DATA LEAK VIA ANALYTICS PLATFORM

Unusual Access and Export from Sensitive Power BI Dataset

This scenario detects when a user accesses and exports a large or sensitive Power BI
dataset especially if they do not normally interact with it. Attackers or insider threats may
use analytics platforms to exfiltrate structured data under the radar.

MITRE ATT&CK Mapping:

• T1213.002 – Data from Information Repositories: Business Intelligence

• T1078 – Valid Accounts
• T1537 – Transfer Data to Cloud Account
• T1567.001 – Exfiltration Over Web Service

Data Source:

• Power BI Activity Logs (via Microsoft Purview / Audit Logs)

• Microsoft Defender for Cloud Apps
• Azure AD Sign-in Logs
• Information Protection Sensitivity Labels

Log Data:

Timesta UserPrincipal Activity Type Dataset Sensiti Exp IP Resu

mp Name Name vity ort Addres lt
(UTC) Label Typ s
e
2025- syakir.khalid@ ExportReport Finance_Q Confid PD 160.12. Succ
06- corp.com 2_Model ential F 88.19 ess
30T09:1
4:05Z
2025- syakir.khalid@ ExportUnderl Finance_Q Confid XLS 160.12. Succ
06- corp.com yingData 2_Model ential X 88.19 ess
30T09:1
4:55Z
2025- syakir.khalid@ ExportData Finance_Q Confid CS 160.12. Succ
06- corp.com 2_Model ential V 88.19 ess
30T09:1
5:40Z

The user has not accessed this dataset in the past 60 days. Data includes salary
breakdown, budget forecast and unreleased earnings report.
Alert Logic / Rule:

Detection Name: Export of Confidential Power BI Dataset by Infrequent User

Trigger Conditions:

1. Power BI dataset labeled “Confidential” or higher is exported.

2. User has not accessed the dataset in the past 30–60 days.
3. Export includes ExportUnderlyingData, ExportData or full ExportReport.
4. Optional: File size or export format indicates potential for data extraction.

KQL Query Example (Sentinel):

OfficeActivity
| where RecordType == "PowerBI"
| where Operation in ("ExportReport", "ExportData", "ExportUnderlyingData")
| where SensitiveLabel == "Confidential"
| summarize CountExports = count(), LastAccess = max(TimeGenerated)
by UserId, DatasetName, ExportType, ClientIP
| where CountExports > 1

Alert Output:

Title: Export of Confidential Power BI Dataset by Unusual User

Severity: High
User: [email protected]
Description: A user who has not interacted with the Power BI dataset Finance_Q2_Model in
the last 60 days has exported it in three formats (PDF, XLSX, CSV). The dataset is tagged as
“Confidential” and contains financial data.

Analyst Investigation Steps:

1. Validate User Role:

o Is [email protected] a member of the Finance or BI team?
o Do they require this data for work purposes?
2. Review Export Context:
o Was this access part of a scheduled report or ad-hoc pull?
o Was the export sent or stored externally?
3. Sensitivity Label Check:
o Confirm the dataset’s label and associated data protection settings.
o Is the data protected via encryption or sharing restrictions?
4. Download Destination Monitoring:
o Any file sharing or cloud sync (e.g., OneDrive, Box, USB)?
o Use Defender for Endpoint or MCAS integrations if available.
5. Cross-Reference With Sign-In:
 o Is 160.12.88.19 a valid corporate IP or known device?

Recommendation:

• Immediate:
o Notify the user’s manager and data protection officer.
o Restrict access to the Power BI workspace if policy violation is suspected.
o Place a hold on the user’s OneDrive if export continued to external systems.
• Medium-Term:
o Enforce export controls on sensitive datasets via DLP or MCAS policies.
o Enable justification prompts for data exports from classified models.
• Long-Term:
o Use sensitivity labels to restrict export permissions by group or location.
o Enable Power BI anomaly detection for large or unusual export volumes.
SCENARIO 11: CREATION OF NEW OAUTH APP WITH BROAD
PERMISSIONS BY INTERNAL USER — SHADOW IT OR MALICIOUS INTENT

Unapproved Internal OAuth App Registration with Risky Scopes

This scenario flags the registration of a new enterprise application (OAuth app) within
Azure AD by a standard internal user, especially when it requests broad scopes such as
Mail.ReadWrite, Files.Read.All or User.Read.All. This may indicate shadow IT, risky
automation or malicious intent.

MITRE ATT&CK Mapping:

• T1550.001 – Steal or Abuse Access Tokens

• T1586.003 – Create Cloud Application
• T1078 – Valid Accounts
• T1529 – System or Service Discovery

Data Source:

• Azure AD Audit Logs

• Microsoft Defender for Cloud Apps (OAuth App Governance)
• Entra ID Enterprise Applications Logs
• Purview Audit Logs

Log Data:

Timesta UserPrincipal Activi App Permission Cons IP Resul

mp (UTC) Name ty Display s ent Address t
Name Requested Type
2025-06- ali.roslan@cor Add AutoEma Mail.Read User 103.212.6 Succ
30T10:21 p.com OAut ilBot Write, 5.10 ess
:12Z h App Files.Read.
All,
User.Read.
All
2025-06- ali.roslan@cor Grant AutoEma Same as Admi 103.212.6 Succ
30T10:22 p.com Admi ilBot above n 5.10 ess
:05Z n
Cons
ent

An internal user registered a new OAuth app and granted it full mail and file access,
without prior admin approval or change request.
Alert Logic / Rule:

Detection Name: Internal Registration of High-Risk OAuth App

Trigger Conditions:

1. A new application is registered (Add OAuth App) by a non-admin user.

2. The app requests risky or broad scopes (Files.Read.All, Mail.ReadWrite,
User.Read.All, etc.).
3. Consent is granted (user or admin), especially without approval via Microsoft Entra
ID workflows.
4. Optional: IP address is new or uncommon for sensitive operations.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Add service principal"
| extend AppName = tostring(TargetResources[0].displayName), User =
InitiatedBy.user.userPrincipalName
| join kind=inner (
AuditLogs
| where ActivityDisplayName == "Consent to application"
| extend Permissions =
tostring(parse_json(TargetResources[0].modifiedProperties)[*].NewValue)
) on $left.AppName == $right.TargetResources[0].displayName
| where Permissions has_any ("Mail.ReadWrite", "Files.Read.All", "User.Read.All")
| project TimeGenerated, AppName, User, Permissions, InitiatedBy, IPAddress

Alert Output:

Title: Risky Internal OAuth App Registered — AutoEmailBot

Severity: High
User: [email protected]
Description: An internal user registered a new OAuth application named AutoEmailBot and
granted it high-risk scopes without an admin workflow or pre-approval. These permissions
include full access to mailboxes, files and user profiles.

Analyst Investigation Steps:

1. Verify Purpose:
o Is AutoEmailBot part of a sanctioned automation effort?
o Is there documentation or a change request ticket?
2. User Role Validation:
o Is [email protected] authorised to create such integrations?
o Is this behaviour consistent with their role or past activities?
 3. Review App Behaviour:
o Check audit logs for what the app accessed post-consent.
o Look for spikes in email read/write or file access activities.
4. Threat Intelligence Check:
o Is the app name used in known abuse campaigns?
o Is the IP (103.212.65.10) tied to other suspicious actions?
5. Correlate with Other Events:
o Were similar apps registered recently by other users?

Recommendation:

• Immediate:
o Revoke app token and delete the application registration.
o Alert user’s manager and security team for awareness.
• Medium-Term:
o Enforce admin consent policies for high-privilege scopes.
o Require justification and approval for all app registrations.
• Long-Term:
o Use Defender for Cloud Apps App Governance module to audit risky app
activity.
o Set Conditional Access policies to block unknown or high-risk OAuth apps.
SCENARIO 12: MULTIPLE CONSENT GRANTS TO THE SAME THIRD-PARTY
APP ACROSS DIFFERENT USERS — COORDINATED PHISHING CAMPAIGN

Widespread OAuth Consent Phishing Detected Across Tenant

This scenario highlights when a third-party OAuth application (often malicious or

compromised) is granted access by multiple users across the tenant in a short timeframe.
This is typical of a coordinated phishing campaign that uses a consent link to bypass
traditional credential theft mechanisms and gain persistent API-level access.

MITRE ATT&CK Mapping:

• T1550.001 – Application Access Token

• T1585.002 – Abuse of Trusted Third-party OAuth App
• T1078 – Valid Accounts
• T1566.002 – Spearphishing Link

Data Source:

• Azure AD Audit Logs

• Microsoft Defender for Cloud Apps
• Microsoft Entra ID Enterprise Application Logs
• Unified Audit Logs from Microsoft Purview

Log Data:

Timestam UserPrincipalNam Activity App Permission IP Result

p (UTC) e Display s Granted Address
Name
2025-06- siti.mariam@corp. Consent QuickD Mail.Read, 185.77.44 Succe
30T09:02: com to ocs offline_acc .88 ss
11Z applicati View Pro ess
on
2025-06- azlan.hamid@corp Consent QuickD Mail.Read, 185.77.44 Succe
30T09:07: .com to ocs offline_acc .88 ss
56Z applicati View Pro ess
on
2025-06- ezzati.yunus@cor Consent QuickD Mail.Read, 185.77.44 Succe
30T09:13: p.com to ocs offline_acc .88 ss
32Z applicati View Pro ess
on
The same application was granted access by 3 unrelated users in <15 minutes, from the
same IP range. Scopes allow persistent access to email without the need for MFA
reauthentication.

Alert Logic / Rule:

Detection Name: Multiple OAuth Consents to Same App Across Tenant

Trigger Conditions:

1. ≥2 users grant consent to the same application within <30 minutes.

2. Application requests persistent access (e.g., Mail.Read, Files.Read.All,
offline_access).
3. IP range is identical or geolocation is abnormal.
4. Optional: App is not previously seen in tenant.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName), User =
InitiatedBy.user.userPrincipalName
| summarize ConsentCount = count(), Users = make_set(User),
StartTime=min(TimeGenerated), EndTime=max(TimeGenerated)
by AppName
| where ConsentCount >= 2 and EndTime - StartTime < 30m

Alert Output:

Title: Coordinated OAuth Consent Phishing — App: QuickDocs View Pro

Severity: High
Description: Multiple internal users across different departments granted access to the
same OAuth app QuickDocs View Pro, requesting Mail.Read and offline_access scopes
within a short period. This behaviour suggests a phishing campaign exploiting trust in third-
party apps.

Analyst Investigation Steps:

1. Validate User Awareness:

o Ask users if they intended to grant access to the app.
o Review email inbox for phishing links or suspicious emails.
2. Review App Behaviour:
o Has the app accessed email or downloaded attachments?
o Check activity logs for Graph API calls via this app.
3. IP Intelligence:
 o Is 185.77.44.88 part of known threat infrastructure?
o Were the grants triggered via an embedded browser or link?
4. Scope & Risk Analysis:
o Were other high-risk scopes (e.g., SendMail, Files.ReadWrite) requested?
o Does the app also attempt impersonation (User.Read.All)?
5. Check for Lateral Movement:
o Were internal phishing or data access attempts made after the grant?

Recommendation:

• Immediate:
o Revoke consent for the app across all users using Microsoft Entra ID or
MDCA.
o Disable the app’s access token and investigate any associated service
principals.
o Notify impacted users and perform password resets.
• Medium-Term:
o Enable admin-only consent for all non-Microsoft apps.
o Block risky applications via Conditional Access App Control.
• Long-Term:
o Implement OAuth app governance with Defender for Cloud Apps.
o Add automatic alerting for mass consent events across the tenant.
SCENARIO 13: MASS DELETION OF FILES FROM ONEDRIVE OR
SHAREPOINT — POTENTIAL RANSOMWARE OR MALICIOUS INSIDER
ACTIVITY

Unusual File Deletion Spike — Possible Data Destruction or Ransomware Event

This scenario detects mass deletion of files by a single user from SharePoint or OneDrive in
a short timeframe. This pattern may indicate attempted data destruction, insider sabotage
or the initial stages of a ransomware attack (e.g., deleting original files before ransom note
upload).

MITRE ATT&CK Mapping:

• T1485 – Data Destruction

• T1078 – Valid Accounts
• T1490 – Inhibit System Recovery
• T1565.001 – Stored Data Manipulation: SharePoint and OneDrive

Data Source:

• Microsoft Purview Audit Logs (SharePoint/OneDrive File Activities)

• Microsoft Defender for Cloud Apps
• Defender for Endpoint (if ransomware is involved)
• Microsoft 365 Compliance Center Alerts

Log Data:

Timestam UserPrincipalNa Activity File Site/Source IP Resul

p (UTC) me Type Name Address t
2025-06- aiman.musa@cor FileDele Q1- /OneDrive/a. 103.22.8 Succe
30T10:15: p.com ted Report.xl musa 0.10 ss
10Z sx
2025-06- aiman.musa@cor FileDele Project- /OneDrive/a. 103.22.8 Succe
30T10:15: p.com ted Plan.doc musa 0.10 ss
15Z x
2025-06- aiman.musa@cor FileDele HR- /OneDrive/a. 103.22.8 Succe
30T10:15: p.com ted Salaries. musa 0.10 ss
22Z csv
2025-06- aiman.musa@cor FileDele Clients- /OneDrive/a. 103.22.8 Succe
30T10:15: p.com ted 2025.xls musa 0.10 ss
35Z x
 2025-06- aiman.musa@cor FileDele IT- /OneDrive/a. 103.22.8 Succe
30T10:15: p.com ted Budget. musa 0.10 ss
50Z pptx

Over 20 files deleted from OneDrive in <2 minutes from a non-corporate IP. Files include
critical and sensitive documents.

Alert Logic / Rule:

Detection Name: Mass File Deletion in M365 Storage by Single User

Trigger Conditions:

1. ≥10 FileDeleted events by the same user within <5 minutes.

2. Files from different folders or sites (broad scope).
3. IP address is new or non-corporate.
4. Optional: Device is unmanaged or non-compliant.

KQL Query Example (Sentinel):

OfficeActivity
| where RecordType in ("SharePointFileOperation", "OneDriveFileOperation")
| where Operation == "FileDeleted"
| summarize DeletionCount = count(), FirstSeen = min(TimeGenerated), LastSeen =
max(TimeGenerated)
by UserId, ClientIP
| where DeletionCount >= 10 and LastSeen - FirstSeen < 5m

Alert Output:

Title: Unusual File Deletion from OneDrive — Potential Data Destruction

Severity: High
User: [email protected]
Description: Over 20 files were deleted from user OneDrive storage in under 2 minutes
from IP 103.22.80.10, which is not a registered corporate address. Files affected include
HR and financial content.

Analyst Investigation Steps:

1. User Intent Check:

o Contact the user: Was this a planned cleanup or unintentional action?
o Any recent issues with sync or file access?
2. Location/IP Review:
o Is IP 103.22.80.10 part of approved VPN or endpoint network?
o Review user sign-in logs for anomalies.
 3. File Analysis:
o Were files recoverable from Recycle Bin or version history?
o Were copies exfiltrated prior to deletion?
4. Ransomware Signs:
o Check Defender for Endpoint logs: any file encryption or ransom notes?
o Scan endpoint for known ransomware indicators.
5. Correlate with Previous Events:
o Was there an OAuth app consent, strange login or MFA fatigue event earlier?

Recommendation:

• Immediate:
o Block user access and investigate endpoint.
o Restore files via OneDrive/SharePoint recovery tools.
o Alert DLP and incident response team.
• Medium-Term:
o Enforce file deletion limits via MCAS session policies.
o Tag sensitive files with sensitivity labels for auto-alerting.
• Long-Term:
o Implement insider risk policies and UEBA models for abnormal
delete/download.
o Educate users on safe OneDrive file handling and sync settings.
SCENARIO 14: EXTERNAL USER ADDED TO MICROSOFT TEAMS WITH ACCESS TO
SENSITIVE FILES — POTENTIAL DATA EXPOSURE

Sensitive Team Shared with External User Without Approval

This scenario flags the addition of an external (guest) user to a Microsoft Teams channel or
SharePoint site linked to a sensitive project, department or dataset. This often occurs
unintentionally or due to overly permissive collaboration settings and can lead to
accidental data exposure or compliance violations.

MITRE ATT&CK Mapping:

• T1190 – Exploit Public-Facing Application (collab abuse)

• T1078 – Valid Accounts (external/guest access)
• T1213 – Data from Information Repositories
• T1537 – Transfer Data to Cloud Account

Data Source:

• Azure AD Audit Logs

• Microsoft Teams Activity Logs
• SharePoint Site Sharing Logs
• Microsoft Defender for Cloud Apps
• Microsoft Purview (Information Protection Labels)

Log Data:

Timest Performed By Activi External User Target Site IP Res

amp ty Email Team/Si Sensit Addres ult
(UTC) Type te ivity s
2025- nabila.kassim@ Add jwalker.contract /teams/ Confi 202.18 Suc
06- corp.com mem [email protected] Finance dentia 8.66.5 ces
30T11: ber -Q3 l 5 s
42:05Z
2025- jwalker.contract FileA - /teams/ Confi 202.18 Suc
06- [email protected] cces Finance dentia 8.66.5 ces
30T11: s -Q3 l 5 s
44:12Z

A confidential finance team was shared with an external contractor email address. No
formal access request or third-party NDA was logged.

Alert Logic / Rule:

Detection Name: External Guest Added to Sensitive Team or Site
Trigger Conditions:

1. External user (email not ending with internal domain) added to a Microsoft Team or
SharePoint site.
2. Target site/team is labelled “Confidential” or “Internal Only”.
3. Optional: Performed by a non-admin user or outside approved process.
4. First-time file access follows the addition within <10 minutes.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Add member to group"
| where TargetResources[0].userPrincipalName !endswith "@corp.com"
| join kind=inner (
OfficeActivity
| where Operation == "FileAccessed"
) on $left.TargetResources[0].userPrincipalName == $right.UserId
| where TimeGenerated1 - TimeGenerated < 10m
| project TimeGenerated, PerformedBy = InitiatedBy.user.userPrincipalName, GuestUser =
TargetResources[0].userPrincipalName, TeamOrSite, SensitivityLabel

Alert Output:

Title: External User Added to Confidential Team — Immediate File Access

Severity: High
Performed By: [email protected]
Guest: [email protected]
Description: An external user was added to a Microsoft Team labelled “Confidential” and
began accessing files within 2 minutes. No request or approval workflow was triggered,
indicating potential data governance violation.

Analyst Investigation Steps:

1. Validate Intent:
o Was the external user officially onboarded or part of a project?
o Is there a ticket or documented business reason for this access?
2. Review User History:
o Is [email protected] a recurring or first-time guest?
o Have they accessed other teams/sites in the past?
3. Content Sensitivity Check:
o Were sensitive financial files accessed, downloaded or shared?
o Is information protection labelling enforced on files?
4. Sharing Policy Check:
 o Is the site or team governed by external sharing policies?
o Does this align with the organisation's data protection policy?

Recommendation:

• Immediate:
o Remove the external user from the team.
o Notify the data owner and information security team.
o Audit all file access and downloads by the guest account.
• Medium-Term:
o Implement Microsoft Purview auto-label policies to restrict external access.
o Enable guest access approval workflows in Teams and SharePoint.
• Long-Term:
o Conduct periodic review of all external users in Microsoft 365.
o Enforce Conditional Access for external identities (e.g., MFA, session limits).
SCENARIO 15: TOKEN REPLAY ATTACK DETECTED VIA ANOMALOUS USE
OF REFRESH TOKEN — POSSIBLE SESSION HIJACKING

Suspicious Reuse of Refresh Token from Different Locations or Devices

This scenario detects abnormal usage of the same Azure AD refresh token from
geographically or contextually distinct environments. Attackers may attempt a token
replay attack using a stolen token to impersonate a user without triggering MFA or login
prompts.

MITRE ATT&CK Mapping:

• T1550.001 – Use of Stolen Access or Refresh Tokens

• T1078.004 – Valid Accounts: Cloud Accounts
• T1021.001 – Remote Services: Cloud APIs
• T1530 – Data from Cloud Storage

Data Source:

• Azure AD Sign-in Logs

• Microsoft Defender for Cloud Apps (MDCA)
• Microsoft Entra ID Risk Detection
• Defender for Identity (if federated identity is in use)

Log Data:

Timestam UserPrincipalN Toke Acti Device IP Locati App Resul

p (UTC) ame n on Address on Use t
Type d
2025-06- anis.nazri@cor Refre Toke WIN- 102.88.22 Kuala Tea Succe
30T12:01: p.com sh n AGEN .99 Lump ms ss
10Z Toke Use T-20 ur
n d
2025-06- anis.nazri@cor Refre Toke Unkno 185.23.56 Polan Tea Succe
30T12:02: p.com sh n wn .190 d ms ss
43Z Toke Use Device
n d

The same refresh token was used from two distinct locations and devices within 2
minutes, bypassing any login prompts or MFA enforcement.

Alert Logic / Rule:

Detection Name: Refresh Token Replay from Anomalous Locations
Trigger Conditions:

1. Same refresh token ID or session ID used from different IPs/devices within a short
time.
2. One or more of the locations is new or high-risk.
3. No interactive login only token-based session continuation.
4. Optional: Defender for Cloud Apps flags as “Impossible Travel” or “Token
Anomaly.”

KQL Query Example (Sentinel):

SigninLogs
| where TokenIssuerType == "AzureAD" and AuthenticationRequirement ==
"multiFactorAuthentication"
| summarize count(), DistinctIPs = dcount(IPAddress), DistinctDevices =
dcount(DeviceDetail)
by CorrelationId, UserPrincipalName
| where DistinctIPs > 1 and DistinctDevices > 1

Alert Output:

Title: Suspicious Replay of Refresh Token by [email protected]

Severity: High
Description: The same Azure AD refresh token was reused from Kuala Lumpur and Poland
within 2 minutes. This may indicate token theft and session hijacking. No interactive login
or MFA challenge was triggered.

Analyst Investigation Steps:

1. Token Usage Validation:

o Was the user active in both sessions or only one?
o Did the device in Poland ever belong to the user?
2. Session Details Review:
o Check CorrelationId, device fingerprint and IPs used.
o Was there any unusual user-agent string or API call?
3. Threat Intelligence Check:
o Is 185.23.56.190 tied to known malicious infrastructure?
o Were there phishing or malware incidents before the session?
4. Defender for Cloud Apps Correlation:
o Any risky app usage, impossible travel or anomaly detection?
o Any file or mail exfiltration during the session?

Recommendation:
• Immediate:
o Revoke all refresh and access tokens for [email protected].
o Force re-authentication with MFA and terminate sessions.
o Block or monitor the foreign IP.
• Medium-Term:
o Enable token protection policies (preview feature in Entra).
o Monitor session token reuse across tenant.
• Long-Term:
o Educate users on phishing attacks that lead to token theft.
o Integrate UEBA and MCAS risk-based Conditional Access enforcement.
SCENARIO 16: SUSPICIOUS MODIFICATION OF MAILBOX PERMISSIONS —
POTENTIAL INSIDER THREAT OR PERSISTENCE SETUP

Unauthorized Grant of Full Mailbox Access to Another User

This scenario detects when a user mailbox is configured to allow another user full access
without proper delegation or change request. This is a common tactic used in both insider
threats and account takeover persistence, allowing covert access to sensitive email
communications.

MITRE ATT&CK Mapping:

• T1098 – Account Manipulation

• T1078 – Valid Accounts
• T1021.004 – Remote Email Collection
• T1556 – Modify Authentication Process

Data Source:

• Microsoft Purview Audit Logs (Mailbox Permissions)

• Exchange Admin Activity Logs
• Microsoft Defender for Cloud Apps
• Microsoft Entra ID Role Assignments (if delegated via admin access)

Log Data:

Timesta Initiated By Target Mailbox Permission Acces IP Resu

mp Granted To s Type Address lt
(UTC)
2025- zainab.nasir@ fadhil.rahman@ khairi.alias@c FullAc 138.22.5 Succ
06- corp.com corp.com orp.com cess 5.101 ess
30T13:2
0:05Z
2025- khairi.alias@c fadhil.rahman@ Accessed Read 138.22.5 Succ
06- orp.com corp.com mailbox items 5.101 ess
30T13:2
1:50Z

Full mailbox access was granted to [email protected] without a recorded approval or

service ticket. Followed by direct access to inbox content within 2 minutes.

Alert Logic / Rule:

Detection Name: Unauthorized Mailbox Access Delegation
Trigger Conditions:

1. Add-MailboxPermission or equivalent operation logged in audit logs.

2. AccessRights = FullAccess or SendAs, applied without prior admin change
approval.
3. Target and grantee are not in the same team, department or delegation group.
4. Access is followed by mailbox activity by the grantee within a short time.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "Add mailbox permissions"
| extend Mailbox = TargetResources[0].userPrincipalName, Grantee =
tostring(parse_json(InitiatedBy.user.userPrincipalName))
| where Result == "Success"
| join kind=inner (
OfficeActivity
| where Operation == "MailItemsAccessed"
) on $left.Mailbox == $right.UserId
| where TimeGenerated1 - TimeGenerated < 5m

Alert Output:

Title: Mailbox Full Access Granted and Immediately Used — [email protected]

Severity: High
Description: The user [email protected] granted full mailbox access of
[email protected] to [email protected], followed by access activity from the
grantee. This occurred without delegation records or formal change approval.

Analyst Investigation Steps:

1. Access Justification Check:

o Is [email protected] officially authorised to access
[email protected]'s mailbox?
o Any change request or ticket related to this delegation?
2. Access Behaviour Review:
o What folders or items were accessed? Were emails downloaded or
forwarded?
o Were any rules or auto-forwarding created afterward?
3. IP and Location Analysis:
o Is 138.22.55.101 a corporate or known network?
o Has this IP been associated with other suspicious activity?
4. Mailbox Sensitivity Check:
 o Is the target mailbox used for executive or finance functions?
o Any classified content or sensitive client communication?

Recommendation:

• Immediate:
o Remove mailbox permission granted to [email protected].
o Notify mailbox owner and data protection team.
o Suspend access and initiate investigation if unauthorised.
• Medium-Term:
o Review all mailboxes with delegated permissions across tenant.
o Require approvals and ticket references for all mailbox permission changes.
• Long-Term:
o Enforce Microsoft Purview Insider Risk policies to flag abnormal access.
o Implement automation via Sentinel or MCAS to detect suspicious mailbox
delegations.
SCENARIO 17: EXCHANGE TRANSPORT RULE CREATED TO REDIRECT
EMAILS TO EXTERNAL ADDRESS — COVERT MONITORING OR DATA LEAK

Suspicious Mail Flow Rule Redirecting Internal Emails to External Account

This scenario detects the creation of a new Exchange Transport Rule (ETR) configured to
redirect or blind-copy all emails to an external address. This tactic is often used by
attackers post-compromise to monitor communications, steal data or maintain covert
visibility without modifying mailbox contents.

MITRE ATT&CK Mapping:

• T1114.003 – Email Collection: Email Forwarding Rule

• T1098 – Account Manipulation
• T1078 – Valid Accounts
• T1567.002 – Exfiltration to Cloud Storage

Data Source:

• Exchange Online Audit Logs

• Microsoft Purview Audit Logs
• Microsoft Defender for Office 365 (Exchange transport rule monitoring)
• Azure AD Role Assignment Logs (if admin elevation was needed)

Log Data:

Timesta Initiated By Activi Rule Name Redirect To Tar IP Resu

mp ty get Addres lt
(UTC) Type Sco s
pe
2025- ilyas.hamzah Creat covert_mo attacker.alerts All 197.33. Succ
06- @corp.com e nitoring @mail.com use 88.10 ess
30T13:5 Trans rs
8:45Z port
Rule

The new rule redirects all mail received by any internal user to an external email address,
without their knowledge. Created from an unusual IP address and user account without
prior administrative activity.

Alert Logic / Rule:

Detection Name: Exchange Rule Redirecting Mail to External Recipient

Trigger Conditions:
 1. New Exchange Transport Rule created with actions like RedirectMessageTo,
AddToRecipient, BccTo.
2. Target address is external and not in the allowlist.
3. Initiator is not a global/exchange admin (or is anomalous).
4. IP address is previously unseen or outside corporate range.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName == "New transport rule created"
| extend RuleName = tostring(TargetResources[0].displayName)
| extend Action =
tostring(parse_json(TargetResources[0].modifiedProperties)[*].NewValue)
| where Action has_any("RedirectMessageTo", "AddToRecipient", "BccTo")
| where Action contains "@"
| where Action !endswith "@corp.com"
| project TimeGenerated, InitiatedBy, RuleName, Action, IPAddress

Alert Output:

Title: Suspicious Exchange Transport Rule Redirecting Emails Externally

Severity: Critical
User: [email protected]
Description: A transport rule named covert_monitoring was created to redirect all internal
email to [email protected]. This activity occurred from IP 197.33.88.10 using a
user account with no recent administrative activity.

Analyst Investigation Steps:

1. Verify Rule Creation:

o Was there an approved change or admin delegation for this rule?
o Is the user account supposed to manage transport settings?
2. Check for Other Malicious Rules:
o Review all transport and inbox rules in Exchange Online.
o Audit mailbox rules for similar forwarding behaviour.
3. Correlate with User Activity:
o Any unusual sign-ins, MFA fatigue, OAuth app consents?
o Is the IP (197.33.88.10) geolocated to an expected region?
4. Review Email Flow:
o Did any sensitive emails get redirected before detection?
o Were recipients notified or kept unaware?

Recommendation:
• Immediate:
o Delete the transport rule immediately.
o Suspend the user account and revoke all access.
o Notify incident response and compliance teams.
• Medium-Term:
o Enable audit alerting for all new transport rules.
o Require administrative approval for mail flow rule creation.
• Long-Term:
o Use Microsoft Purview DLP and MCAS anomaly policies for email redirection.
o Harden Exchange admin permissions and role-based access.
SCENARIO 18: ABNORMAL POWERSHELL ACTIVITY USING EXCHANGE ONLINE
MANAGEMENT — POSSIBLE RECON OR BACKDOOR SETUP

Suspicious PowerShell Connection to Exchange Online via Remote Session

This scenario detects the use of remote PowerShell (e.g., Exchange Online PowerShell or
Connect-ExchangeOnline) by an internal or compromised user to enumerate mailboxes,
modify permissions or establish persistence. While legitimate administrators use
PowerShell regularly, attackers often abuse it post-compromise to silently manipulate
mail flow or gather intelligence.

MITRE ATT&CK Mapping:

• T1059.001 – Command and Scripting Interpreter: PowerShell

• T1087.003 – Account Discovery: Email Accounts
• T1098 – Account Manipulation
• T1565.001 – Stored Data Manipulation: Email

Data Source:

• Microsoft Purview Audit Logs

• Microsoft Defender for Cloud Apps
• Exchange Online Admin Logs
• Microsoft 365 Unified Audit Log
• Defender for Endpoint (PowerShell usage)

Log Data:

Timestam UserPrincipalNam Activity Type Command IP Address Result

p (UTC) e Executed
2025-06- hafiz.rahman@cor PowerShellConn Connect- 203.222.1 Succe
30T14:25: p.com ection ExchangeOnli 1.22 ss
10Z ne
2025-06- hafiz.rahman@cor CommandExecu Get-Mailbox - 203.222.1 Succe
30T14:26: p.com ted ResultSize 1.22 ss
22Z Unlimited
2025-06- hafiz.rahman@cor CommandExecu Add- 203.222.1 Succe
30T14:27: p.com ted MailboxPermi 1.22 ss
01Z ssion -User
[email protected]
m-
AccessRights
FullAccess
PowerShell session was initiated from an external IP not associated with the organisation
and the user granted full mailbox access to an external account. No prior record of admin-
level PowerShell usage by this user.

Alert Logic / Rule:

Detection Name: Abnormal Exchange PowerShell Activity by Non-Admin

Trigger Conditions:

1. Connect-ExchangeOnline invoked by user who is not in known admin groups.

2. Commands executed include Get-Mailbox, Add-MailboxPermission or New-
InboxRule.
3. IP address is external or new.
4. Optional: Target user or mailbox is high-risk or labelled sensitive.

KQL Query Example (Sentinel):

AuditLogs
| where Operation == "Connect-ExchangeOnline" or Operation ==
"PowerShellCommandInvoked"
| where UserId !in ("KnownAdminsGroup")
| extend CommandText = tostring(parse_json(ModifiedProperties)[*].NewValue)
| where CommandText has_any ("Get-Mailbox", "Add-MailboxPermission", "New-
InboxRule")
| project TimeGenerated, UserId, CommandText, IPAddress

Alert Output:

Title: Suspicious Remote PowerShell Commands Executed by [email protected]

Severity: Critical
Description: A PowerShell session was established from IP 203.222.11.22 and Exchange
mailbox discovery and manipulation commands were executed by a user who is not a
member of the admin group. One command granted full access to an external user
([email protected]), indicating potential malicious intent.

Analyst Investigation Steps:

1. User Access Validation:

o Is [email protected] authorised to use remote PowerShell for
Exchange?
o Has the user performed similar actions historically?
2. IP and Device Verification:
o Is 203.222.11.22 an approved VPN or admin workstation?
o Was Defender for Endpoint active on the user's device?
 3. Command Impact Review:
o Which mailboxes were accessed or modified?
o Were forwarding rules or permissions changed?
4. Reconnaissance Detection:
o Was Get-Mailbox, Get-InboxRule or Search-Mailbox used extensively?
o Were any user lists exported or filtered by role or group?

Recommendation:

• Immediate:
o Terminate PowerShell session and block external access from IP.
o Revoke delegated access and reset affected user passwords.
o Suspend the user account pending investigation.
• Medium-Term:
o Implement Conditional Access policy to block legacy auth and remote
PowerShell use unless approved.
o Monitor PowerShell session initiations from non-admins.
• Long-Term:
o Enable role-based access control and logging for all Exchange cmdlets.
o Configure alerting for non-standard PowerShell behaviour in the tenant.
SCENARIO 19: ATTEMPTED BYPASS OF CONDITIONAL ACCESS POLICY
VIA LEGACY AUTHENTICATION CLIENT

Conditional Access Bypass Attempt via Unsupported Legacy Client

This scenario detects an authentication attempt using an outdated client (e.g., older
versions of Outlook, Office 2010, IMAP or POP) that does not support Conditional Access
enforcement. This could be an attacker trying to bypass modern MFA or risk-based policies
enforced only on modern protocols.

MITRE ATT&CK Mapping:

• T1078.004 – Valid Accounts: Cloud Accounts

• T1556.004 – Bypass User Account Control or Conditional Policies
• T1110 – Brute Force
• T1550.001 – Use of Valid Application Access

Data Source:

• Azure AD Sign-in Logs

• Microsoft Entra Conditional Access Insights & Reporting
• Microsoft Defender for Cloud Apps (MCAS)
• Office Activity Logs (optional if Exchange Online is involved)

Log Data:

Timestam UserPrincipalNam Client Authenticati Conditio IP Address Resu

p (UTC) e App on Protocol nal lt
Access
Result
2025-06- daniel.ong@corp. Other POP3 Not 185.123.55. Faile
30T15:10:3 com client Applied 22 d
2Z s
2025-06- daniel.ong@corp. Other IMAP Not 185.123.55. Faile
30T15:11:0 com client Applied 22 d
4Z s
2025-06- daniel.ong@corp. Outlo Basic Auth Not 185.123.55. Faile
30T15:11:4 com ok Applied 22 d
8Z 2010

These attempts originated from the same suspicious foreign IP address using legacy
clients that cannot enforce MFA or Conditional Access. CA policy was not applied due to
protocol limitations.
Alert Logic / Rule:

Detection Name: Legacy Client Used to Circumvent Conditional Access

Trigger Conditions:

1. Sign-in attempts using legacy clients or Basic Auth (e.g., IMAP, POP3, Outlook
2010).
2. Conditional Access Policy result = “Not Applied” or “Not Capable.”
3. IP address is foreign, untrusted or previously unseen.
4. Authentication result = multiple failures or abnormal frequency.

KQL Query Example (Sentinel):

SigninLogs
| where ClientAppUsed in ("IMAP", "POP", "Other clients", "Outlook 2010")
| where ConditionalAccessStatus in ("notApplied", "notCapable")
| where ResultType != 0
| summarize AttemptCount = count(), DistinctApps = make_set(ClientAppUsed)
by UserPrincipalName, IPAddress
| where AttemptCount >= 3

Alert Output:

Title: Legacy Client Attempted to Bypass Conditional Access for [email protected]

Severity: Medium to High
Description: Multiple sign-in attempts were made using legacy authentication protocols
(POP3, IMAP, Outlook 2010) from a foreign IP 185.123.55.22. Conditional Access policies
could not be enforced due to protocol limitations and all attempts failed. This is a known
tactic for bypassing MFA.

Analyst Investigation Steps:

1. User Contact:
o Was [email protected] attempting legitimate access from an old
device?
o Is the user currently travelling or using legacy applications?
2. IP Risk Check:
o Is 185.123.55.22 blacklisted or associated with brute force attempts?
o Any correlation with activity on other accounts?
3. Policy Audit:
o Are legacy authentication protocols still allowed in the tenant?
o Has the user account been targeted by brute force in the past?
4. Cross-Check Devices:
o Are there any approved devices that still use legacy authentication?
 o Was the endpoint involved managed by Intune or Defender for Endpoint?

Recommendation:

• Immediate:
o Block IP 185.123.55.22 via Conditional Access or firewall.
o Investigate any prior successful logins for [email protected].
o Enforce sign-out and reset user credentials if compromise suspected.
• Medium-Term:
o Disable legacy authentication tenant-wide using Entra ID settings.
o Audit all accounts still enabled for legacy protocol access.
• Long-Term:
o Enforce “Require Modern Auth” baseline policies.
o Use MCAS to detect and alert on Basic Auth attempts and legacy client
usage.
SCENARIO 20: UNUSUAL SPIKE IN EDISCOVERY SEARCH OR EXPORT
ACTIVITY — POTENTIAL DATA ABUSE OR INSIDER THREAT

Abnormal Use of eDiscovery Tools for Mass Mailbox Export

Microsoft Purview’s eDiscovery capabilities allow legal, compliance and security roles to
search across mailboxes and export data. When this tool is misused—either by insiders or
compromised privileged accounts—it can lead to large-scale data exfiltration. This
scenario focuses on abnormal or unauthorised use of eDiscovery search/export actions.

MITRE ATT&CK Mapping:

• T1114 – Email Collection

• T1530 – Data from Cloud Storage
• T1078 – Valid Accounts
• T1087 – Account Discovery

Data Source:

• Microsoft Purview Audit Logs (eDiscovery Activities)

• Microsoft Defender for Cloud Apps (MCAS)
• Microsoft Entra ID Privileged Role Assignments
• Unified Audit Logs

Log Data:

Timesta Performed By Activity Case Action Action IP Resul

mp Type Name Target Details Address t
(UTC)
2025-06- sarah.mansor@c eDisco LegalHol All Keywo 45.66.12 Succ
30T16:10 orp.com very dTest mailbo rds: 3.99 ess
:02Z Search xes “invoic
Create e”,
d “proje
ct”,
“bid”
2025-06- sarah.mansor@c eDisco LegalHol All Export 45.66.12 Succ
30T16:12 orp.com very dTest search size: 3.99 ess
:18Z Export results 2.1 GB
Started

The user is not part of the compliance or legal team and has no history of conducting
eDiscovery. Exported data includes executive communications and financial files.
Alert Logic / Rule:

Detection Name: Unauthorised or Abnormal eDiscovery Export Activity

Trigger Conditions:

1. SearchQueryInitiated or ExportStarted event in Microsoft Purview audit logs.

2. Initiated by a user outside of approved compliance, legal or investigation roles.
3. Search scope includes multiple mailboxes, especially executives or finance users.
4. Export size exceeds 1 GB or includes high-sensitivity keywords.

KQL Query Example (Sentinel):

AuditLogs
| where ActivityDisplayName in ("SearchQueryInitiated", "ExportStarted")
| where InitiatedBy.user.userPrincipalName !in ("[email protected]",
"[email protected]")
| extend CaseName = tostring(TargetResources[0].displayName)
| extend ExportSize =
tostring(parse_json(TargetResources[0].modifiedProperties)[*].NewValue)
| where ExportSize contains "GB"
| project TimeGenerated, InitiatedBy, CaseName, ExportSize, IPAddress

Alert Output:

Title: Abnormal eDiscovery Search and Export by Non-Compliance User

Severity: Critical
User: [email protected]
Description: An eDiscovery search and 2.1GB export were executed by a user with no
compliance or legal role membership. Keywords used include financial and executive
terms. Activity occurred from IP 45.66.123.99, which is external to normal office locations.

Analyst Investigation Steps:

1. Validate User Role:

o Is [email protected] authorised for eDiscovery use?
o Has she ever been assigned a legal/investigator role in Entra ID?
2. Investigate Scope:
o What mailboxes and content were targeted in the search?
o Were high-value users (e.g., CEO, CFO) included?
3. Export Review:
o Was the exported content downloaded? Where was it saved?
o Any subsequent upload to OneDrive, Google Drive or email?
4. Location/IP Context:
o Was the IP 45.66.123.99 corporate? VPN? Foreign?
 o Any other security events tied to this IP or session?

Recommendation:

• Immediate:
o Revoke access to Microsoft Purview for [email protected].
o Suspend user account and investigate device activity.
o Notify Data Loss Prevention and Legal teams immediately.
• Medium-Term:
o Restrict eDiscovery access to defined user groups via role-based access
control.
o Enable MCAS and Purview DLP for file movement post-export.
• Long-Term:
o Enable auditing and alerting for all eDiscovery actions above threshold.
o Conduct awareness sessions on proper usage of investigation tools.