Agent Foskett Investigation • Microsoft 365 • Microsoft Graph • Exchange Online • OAuth • Service Principals • KQL
The Attacker Never Opened Outlook — They Read the Mailbox Through Microsoft Graph
The mailbox had been accessed.
So the team went looking for the Outlook session.
Nothing.
No suspicious Outlook sign-in.
No obvious browser session reading the messages.
No neat interactive timeline explaining the access.
Then Agent Foskett asked a different question.
Who said the attacker needed Outlook?
The investigation moved from the mailbox interface to the application and API layer.
The Mailbox Is More Than Outlook
Exchange Online data can be accessed through applications and APIs. When Outlook does not explain the activity, investigate mailbox audit events, application identity and permissions.
✓ Reconstruct mailbox operations
✓ Investigate application identity
✓ Scope other mailboxes and related activity
The Outlook assumption created the blind spot
The investigation began by treating mailbox access as an Outlook problem. But Exchange Online can be accessed through multiple clients and application paths. The absence of a suspicious Outlook session therefore did not prove the mailbox had not been accessed.
No suspicious Outlook sessionThe expected interactive evidence was not there.
Mailbox activity remainedAudit evidence still showed operations that required explanation.
Application access consideredThe investigation widened from the user interface to APIs and workload identities.
Start with the mailbox audit trail
Where Microsoft 365 audit data is connected to Microsoft Sentinel,
OfficeActivity can provide Exchange workload events. Preserve the operation, source IP, client information and parameters rather than assuming which client performed the access.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
let Mailbox = "finance@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where OfficeWorkload == "Exchange"
| where UserId =~ Mailbox
| project TimeGenerated, Operation, UserId, ClientIP,
ClientInfoString, ExternalAccess, ResultStatus, Parameters
| order by TimeGenerated ascNarrow to message access and sending operations
Focus on operations relevant to reading or acting through the mailbox. Availability and exact operation names can vary with auditing configuration, so treat the events actually returned by the tenant as the evidence.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
let Mailbox = "finance@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where OfficeWorkload == "Exchange"
| where UserId =~ Mailbox
| where Operation in ("MailItemsAccessed", "MessageBind", "Send", "SendAs", "SendOnBehalf")
| project TimeGenerated, Operation, UserId, ClientIP,
ClientInfoString, ExternalAccess, Parameters
| order by TimeGenerated ascThe mailbox operation did not require Outlook
Once the audit trail showed mailbox operations without a corresponding suspicious Outlook session, the investigation shifted toward application access. Microsoft Graph is one legitimate way applications can interact with Microsoft 365 data, but the analyst still needs evidence tying the observed activity to a specific application or service principal.
Mailbox operation observedThe audit trail established activity against Exchange Online.
Outlook not requiredApplication and API access can interact with mailbox data without somebody opening Outlook.
Identity still requiredThe next task was to determine which user or application identity was responsible.
Look for service principal authentication
If application-only access is suspected, review Microsoft Entra service principal sign-ins.
AADServicePrincipalSignInLogs can expose the service principal, AppId, target resource, source IP and authentication result when that telemetry is available in Sentinel.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, ServicePrincipalName, ServicePrincipalId,
AppId, ResourceDisplayName, IPAddress,
ResultType, ResultDescription
| order by TimeGenerated descWhat changed on the application?
Once an AppId or service principal is identified, pivot into
AuditLogs. Recent credential, consent, permission or application changes may explain why an established application suddenly gained new capability or began behaving differently.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
let AppIdToCheck = "00000000-0000-0000-0000-000000000000";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has AppIdToCheck
or tostring(InitiatedBy) has AppIdToCheck
| project TimeGenerated, OperationName, Result,
InitiatedBy, TargetResources, AdditionalDetails
| order by TimeGenerated ascDid the same source touch other mailboxes?
Use the suspicious source IP from the mailbox evidence as a scoping pivot. If the same address appears against several mailboxes, the incident may be broader than the first affected account.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let SuspiciousIP = "203.0.113.25";
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where ClientIP has SuspiciousIP
| summarize Operations=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
OperationTypes=make_set(Operation, 20)
by UserId
| order by Operations descBuild a mailbox-access baseline
Summarise relevant Exchange operations by mailbox, source IP and client information. The goal is not to declare every API-style access suspicious, but to identify accounts whose access pattern differs from what the environment normally shows.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where Operation in ("MailItemsAccessed", "MessageBind", "Send", "SendAs", "SendOnBehalf")
| summarize Operations=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
ClientIPs=make_set(ClientIP, 20),
Clients=make_set(ClientInfoString, 20)
by UserId
| order by Operations descDelegated access and application-only access are different
Microsoft Graph can operate with delegated permissions on behalf of a signed-in user or with application permissions using a workload identity. Those models produce different investigative questions.
Delegated accessAn application acts in the context of a signed-in user and granted delegated permissions.
Application accessA workload identity can authenticate using application permissions without an interactive user session at that moment.
Determine which model appliesDo not treat all Microsoft Graph activity as the same authentication path.
What the evidence can and cannot prove
Mailbox audit operations can prove that recorded actions occurred against Exchange Online. Service principal sign-ins can prove that an application identity authenticated to a resource. Neither alone automatically proves that Microsoft Graph was the exact access path or that the activity was malicious. Client details, application identity, permissions and surrounding telemetry must support that conclusion.
ProvenRecorded mailbox operations and authentication events establish what activity occurred.
CorrelateAppId, service principal, client information, IP addresses and permissions connect the evidence.
Do not overclaimNo Outlook session does not automatically prove Graph-based compromise.
Agent Foskett's investigation mindset
Do not confuse an application interface with the underlying data. Outlook is one way to interact with a mailbox; it is not the mailbox itself. When expected Outlook evidence is missing, move down a layer and investigate Exchange operations, application identity, authentication and permissions.
Follow the dataStart with what happened to the mailbox rather than which interface you expected.
Follow the identityDetermine whether a user, application or workload identity authenticated.
Follow the permissionEstablish what allowed the identity to access the mailbox.
Investigation findings
The suspicious mailbox activity could not be explained by an Outlook session alone. Exchange audit evidence established the mailbox operations, while identity and application telemetry provided the pivots needed to investigate API-based access. Modern mailbox investigations must include application identities and API permissions when the user-interface timeline does not fit.
Outlook was not the boundaryThe mailbox could be accessed through other authorised interfaces.
Application identity matteredService principal and AppId evidence became central to the investigation.
Permissions explained capabilityThe investigation had to establish what the application was allowed to do.
Related Agent Foskett investigations
Continue with mailbox, OAuth and application identity investigations.
The User Never Logged In — The Application Did It for ThemInvestigate authentication performed by a workload identity rather than a person.
The OAuth App Consent Was the Real BreachFollow application consent and permissions when the user account itself is not the whole story.
Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
Final thought
A mailbox is a cloud resource, and authorised applications can interact with it through APIs. If the messages were accessed but the Outlook timeline is empty, do not assume the evidence is missing. The investigation may simply be happening at a different layer.
What happened to the mailbox?Start with Exchange audit operations.
Which identity performed it?Investigate user and workload authentication evidence.
What authorised the access?Review application permissions, consent and recent changes.
