4.5 Detection: Bulk Mailbox Access After Account Compromise

The first question in every BEC investigation: what did the attacker read?

MailItemsAccessed logs every email read event in Exchange Online. It records two access types: Bind (individual item accessed, typically from web or mobile clients) and Sync (folder-level synchronization, typically from desktop Outlook). Attackers using EWS or Graph API to harvest email generate Bind events at volumes far exceeding the user's normal pattern.

The detection challenge: MailItemsAccessed generates high volume by design: a user with 50 emails in their inbox generates 50 events every time Outlook syncs. The solution is per-user baselining: compare the current hourly count against the user's 14-day average. A deviation above 3x the baseline, combined with an unfamiliar IP, is the BEC email harvesting signal.

The ClientInfoString field is the second critical signal after volume. It distinguishes how the mailbox was accessed. Outlook desktop shows Client=Microsoft Outlook 16.0. Outlook Web Access shows Client=OWA. Outlook Mobile shows Client=OutlookMobile. But programmatic access. EWS, Graph API, or third-party applications, shows Client=REST or specific application identifiers. An attacker using Graph API to enumerate and download email generates Client=REST events at volumes that stand out against a user whose baseline is Outlook desktop. The combination of volume deviation plus unfamiliar client type plus unfamiliar IP is the three-signal indicator that separates BEC harvesting from normal email use.

The folder access pattern provides additional context. Attackers harvesting email for BEC don't read every email in every folder. They target specific folders: Inbox (recent communications), Sent Items (the user's writing style and communication patterns), Contacts (supplier and partner relationships), and any folder names suggesting financial content (Invoices, Suppliers, Payments). The folder-level breakdown in the second query reveals the attacker's objective.

Licensing requirement: MailItemsAccessed requires Microsoft 365 E5, G5, or A5 (or the Purview Audit Premium add-on). E3 tenants don't generate these events.

Estimated time: 50 minutes.

Rule specification

Hypothesis: An attacker who compromises a mailbox will read email in bulk to find financial data, credentials, or intelligence for BEC operations. This generates MailItemsAccessed volumes 3-10x the user's normal baseline within a single hour. Correlation with an unfamiliar IP confirms the access is by the attacker, not the user.

Data source: OfficeActivity. Operation "MailItemsAccessed", MailboxOwnerUPN, Client_IPAddress, ClientInfoString.

MITRE ATT&CK: Collection → T1114 (Email Collection). T1114.002 (Remote Email Collection).

Severity: High (when combined with unfamiliar IP or preceding anomalous sign-in). Medium (standalone volume anomaly).

The KQL detection query

// Hypothesis: Attacker harvesting email after account compromise
// ATT&CK: T1114.002 (Remote Email Collection)
let baseline_days = 14d;
let anomaly_multiplier = 3.0;
let min_hourly_count = 100;
// Step 1: Build per-user hourly baseline
let user_baseline =
    OfficeActivity
    | where TimeGenerated between(
        ago(baseline_days) .. ago(1d))
    | where Operation == "MailItemsAccessed"
    | where ResultStatus == "Succeeded"
    | summarize HourlyAvg = count() /
        (datetime_diff('hour', ago(1d), ago(baseline_days)))
        by MailboxOwnerUPN;
// Step 2: Current hour activity
let current_activity =
    OfficeActivity
    | where TimeGenerated > ago(1h)
    | where Operation == "MailItemsAccessed"
    | where ResultStatus == "Succeeded"
    | summarize
        CurrentCount = count(),
        IPs = make_set(Client_IPAddress, 10),
        ClientApps = make_set(ClientInfoString, 5)
        by MailboxOwnerUPN;
// Step 3: Compare current to baseline
current_activity
| join kind=inner user_baseline on MailboxOwnerUPN
| where CurrentCount > min_hourly_count
| where CurrentCount > HourlyAvg * anomaly_multiplier
| extend DeviationFactor = round(
    CurrentCount * 1.0 / HourlyAvg, 1)
| project
    MailboxOwnerUPN,
    CurrentCount,
    HourlyAvg = round(HourlyAvg, 0),
    DeviationFactor,
    IPs,
    ClientApps

MailboxOwnerUPN                 CurrentCount  HourlyAvg  DeviationFactor  IPs                    ClientApps
j.harrison@northgateeng.com     847           22         38.5             ["185.234.xx.xx"]      ["Client=REST;Client=RESTful"]

Harrison's hourly average is 22 MailItemsAccessed events. The current hour shows 847: a 38.5x deviation. Walk through the detection signals. The DeviationFactor of 38.5 is far beyond normal variation: even during heavy email days, a user might reach 2-3x their average. A 38x deviation is programmatic access, not a busy afternoon.

The IPs field shows a single external IP (185.234.xx.xx): the attacker's infrastructure, not NE's corporate egress. When a user accesses email from Outlook, the IP is typically their corporate VPN, office network, or mobile carrier. A single unfamiliar IP generating 847 access events in one hour is a strong compromise indicator even before considering the volume anomaly.

The ClientApps field shows Client=REST;Client=RESTful, this is the most important field for distinguishing attacker access from legitimate use. Outlook desktop shows Client=Microsoft Outlook 16.0. Outlook mobile shows Client=OutlookMobile. OWA shows Client=OWA. Client=REST indicates programmatic access through the Exchange Web Services (EWS) or Graph API: the attacker is using an API client or automated tool to harvest email, not reading messages in a mail client. The combination of REST access, external IP, and 38x volume deviation is confirmed credential compromise with active email harvesting.

MailItemsAccessed logs two access types in the MailAccessType field: Bind (individual item access: the user or attacker opens a specific email) and Sync (folder synchronization: the client syncs the entire folder contents). Sync operations generate higher event counts because a single sync can touch hundreds of items. An attacker using EWS typically generates Bind events because they're programmatically accessing individual items by ID. An attacker using Graph API may generate Sync events if they enumerate folder contents first. The investigation script below differentiates these patterns.

Throttling awareness: Microsoft throttles MailItemsAccessed logging at 1,000+ events per 24 hours. If you see exactly 1,000 events followed by a gap, the attacker may have accessed more items than what was logged. Note this in your investigation, assume the full mailbox may have been accessed if throttling occurred. MailItemsAccessed requires E5, G5, or A5 licensing (or the Purview Audit Premium add-on for E3 tenants). Without the appropriate license, MailItemsAccessed events are not logged, and this detection is unavailable.

The Sigma equivalent

title: Bulk Mailbox Access - MailItemsAccessed Volume Anomaly
id: det-soc-011
status: production
description: |
  Detects anomalous MailItemsAccessed volume exceeding 3x the
  user's 14-day hourly average. BEC email harvesting pattern.
  US State Department used this technique to detect Storm-0558.
  Requires M365 E5/G5/A5 (Purview Audit Premium).
author: Ridgeline Cyber Detection Engineering
date: 2026/05/17
tags:
  - attack.collection
  - attack.t1114
  - attack.t1114.002
logsource:
  product: m365
  service: exchange
detection:
  selection:
    Operation: 'MailItemsAccessed'
    ResultStatus: 'Succeeded'
  condition: selection | count() by MailboxOwnerUPN
    per 1h > baseline * 3
falsepositives:
  - Mail migration or archive operations
  - Users returning from extended leave (Outlook catches up)
  - eDiscovery searches
level: medium

PowerShell: scope what the attacker accessed

# Search the Unified Audit Log for detailed access records
$upn = "j.harrison@northgateeng.com"
$start = (Get-Date).AddDays(-7)
$end = Get-Date
$results = Search-UnifiedAuditLog -StartDate $start `
    -EndDate $end -UserIds $upn `
    -Operations "MailItemsAccessed" -ResultSize 5000
# Parse and summarize by folder
$results | ForEach-Object {
    $data = $_.AuditData | ConvertFrom-Json
    [PSCustomObject]@{
        Time      = $data.CreationTime
        IP        = $data.ClientIPAddress
        AppId     = $data.AppId
        AccessType = ($data.OperationProperties |
            Where-Object { $_.Name -eq "MailAccessType" }).Value
        Folder    = $data.Folders.Path
        ItemCount = $data.Folders.FolderItems.Count
    }
} | Group-Object Folder |
    Select-Object Name, Count |
    Sort-Object Count -Descending

Name                     Count
\Inbox                   412
\Sent Items              218
\Contacts                147
\Inbox\Suppliers         70

The attacker focused on Inbox (payment-related emails), Sent Items (to understand Harrison's communication patterns and writing style for BEC), Contacts (to identify supplier relationships), and the Suppliers subfolder (targeted financial information). This access pattern reveals the attacker's objective: understand the payment workflow and supplier relationships to execute a BEC.

Each folder tells you what the attacker was preparing. Inbox access indicates the attacker was reading recent communications to understand ongoing business context. Sent Items access is the BEC preparation step: the attacker needs to mimic Harrison's writing style, tone, and email signature when composing fraudulent messages. The Contacts folder provides the target list: supplier email addresses, internal finance team contacts, and executive contacts. The Suppliers subfolder contains invoice numbers, payment schedules, and bank details: the exact information needed to craft a convincing payment redirection request. This folder breakdown becomes the evidence for your incident report: it demonstrates the attacker's intent and scopes which business relationships were potentially compromised. The folder-level breakdown also determines notification obligations, if the attacker accessed folders containing personal data, privacy regulations may require breach notification.

Entity mapping

The entity mapping connects the Account (whose mailbox was accessed), a second Account entity for the accessor (the compromised account performing the bulk access), and the IP entity. The dual-account mapping is critical: the analyst needs to see both whose data was accessed and who accessed it, especially when the accessor is a delegated account or service principal.

[
  {
    "entityType": "Account",
    "fieldMappings": [{
      "identifier": "FullName",
      "columnName": "MailboxOwnerUPN"
    }]
  }
]

False positive profile and tuning

eDiscovery and legal hold operations generate bulk mailbox access when compliance officers search across mailboxes for litigation or investigation purposes. These use the eDiscovery service account and access patterns are consistent (search, preview, export). Exclude known eDiscovery service accounts.

Migration tools (BitTitan, Quest, Microsoft native migration) access mailboxes in bulk during email migrations. The migration service account and the volume of access (thousands of items per mailbox) distinguish these from attacker access. Suppress during documented migration windows.

Backup solutions (Veeam, Commvault) that include Microsoft 365 mailbox backup access mailboxes programmatically. The backup service account and the predictable daily schedule identify these operations. Exclude backup service accounts.

// What is the normal MailItemsAccessed volume per user?
// Run this to calibrate your 3x threshold
OfficeActivity
| where TimeGenerated > ago(14d)
| where Operation == "MailItemsAccessed"
| summarize HourlyCount = count()
    by MailboxOwnerUPN, bin(TimeGenerated, 1h)
| summarize
    AvgHourly = round(avg(HourlyCount), 0),
    P95Hourly = round(percentile(HourlyCount, 95), 0),
    MaxHourly = max(HourlyCount)
    by MailboxOwnerUPN
| sort by AvgHourly desc
| take 20

Users with high-volume sync patterns (mobile + desktop + web simultaneously) may have legitimate hourly counts of 100-200. The 3x multiplier handles this: a user with a 200-event baseline triggers at 600, not at an absolute threshold. Adjust the multiplier based on your environment — 3x catches most BEC harvesting while tolerating normal variation. If you see frequent false positives at 3x, increase to 5x and add the Client=REST filter as a required condition.