TR1.2 Cloud Evidence Volatility

Figure TR1.2 — Cloud evidence volatility in three categories. Left: capture during triage (time-sensitive). Centre: snapshot during triage (persistent but finite). Right: investigation can collect later (long retention).

Time-sensitive cloud evidence

These evidence categories change or expire on timelines that the triage responder cannot control. Capturing them during the 15-minute triage window is the only way to ensure the investigation team has the data.

Active session tokens

An Entra ID access token is valid for approximately 60-90 minutes (configurable via token lifetime policies, but the default is 1 hour). The refresh token is valid for up to 90 days (configurable, default 90 days for confidential clients). During the triage window, the attacker’s session may still be active — visible in real-time sign-in data with its IP address, device fingerprint, and conditional access evaluation result.

The triage action: query SigninLogs for the affected user’s active sessions in the last 2 hours. Identify which sessions are legitimate (known IP, known device, interactive authentication) and which are suspicious (unknown IP, unknown device, token replay). Revoke all sessions immediately if any suspicious session is identified — this terminates both the legitimate and attacker sessions, but the legitimate user can re-authenticate via MFA while the attacker (whose stolen token is now invalid) cannot.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// TRIAGE QUERY: Active sessions for affected user (last 2 hours)
SigninLogs
| where TimeGenerated > ago(2h)
| where UserPrincipalName == "j.morrison@northgateeng.com"
| where ResultType == "0"  // Successful sign-ins only
| project TimeGenerated, IPAddress, Location = tostring(LocationDetails.city),
    DeviceDetail = tostring(DeviceDetail.displayName),
    AppDisplayName, AuthenticationMethodsUsed = tostring(AuthenticationDetails),
    TokenIssuerType, ConditionalAccessStatus
| sort by TimeGenerated desc

After revocation, re-run this query. Any NEW successful sign-in from the suspicious IP after revocation indicates the attacker has a re-authentication mechanism (fraudulently registered MFA, compromised refresh token from a different session, or a new stolen credential). This changes the containment from session revocation to full credential reset plus MFA method audit.

OAuth consent grants

An attacker who has gained access to a user’s account may grant OAuth consent to a malicious application — allowing the application to read mail, access files, or send emails as the user. The consent grant persists independently of the user’s session: revoking the session does not revoke the OAuth consent. The application continues to access the user’s data using its own tokens, refreshed via the consent grant.

The triage action: query AuditLogs for consent grants by the affected user in the relevant time window.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// TRIAGE QUERY: OAuth consent grants for affected user
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| where InitiatedBy.user.userPrincipalName == "j.morrison@northgateeng.com"
| project TimeGenerated, 
    AppName = tostring(TargetResources[0].displayName),
    AppId = tostring(TargetResources[0].id),
    Permissions = tostring(AdditionalDetails),
    InitiatedByIP = tostring(InitiatedBy.user.ipAddress)
| sort by TimeGenerated desc

Any consent grant from a suspicious IP or during the compromise window must be revoked immediately — this is a containment action, not just evidence collection. An unremediated OAuth grant gives the attacker persistent access that survives password reset, session revocation, and MFA method changes.

Inbox rules and mail flow configuration

Inbox rules are the attacker’s first persistence mechanism in BEC attacks. The CHAIN-HARVEST attacker created a rule forwarding emails containing financial keywords to RSS Subscriptions — hiding the BEC preparation from the legitimate user. The attacker may remove the rule after the BEC email is sent to cover their tracks. If the triage responder does not capture the rule’s existence during triage, the evidence of BEC preparation is lost.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// TRIAGE QUERY: Inbox rules created/modified for affected user
OfficeActivity
| where TimeGenerated > ago(7d)
| where UserId == "j.morrison@northgateeng.com"
| where Operation in ("New-InboxRule", "Set-InboxRule", "Enable-InboxRule")
| project TimeGenerated, Operation, 
    RuleName = tostring(Parameters[0].Value),
    RuleCondition = tostring(Parameters),
    ClientIP
| sort by TimeGenerated desc

MFA method registrations

A compromised account used to register a new MFA method gives the attacker persistent authentication capability. Even after the password is reset and sessions are revoked, the attacker can re-authenticate using the fraudulently registered MFA method. The triage responder must capture the current MFA registration state and identify any methods registered from suspicious IPs or during the compromise window.

1
2
3
4
5
6
7
8
9

// TRIAGE QUERY: MFA registrations for affected user
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "authentication method"
| where TargetResources[0].userPrincipalName == "j.morrison@northgateeng.com"
| project TimeGenerated, OperationName,
    Method = tostring(TargetResources[0].modifiedProperties),
    InitiatedByIP = tostring(InitiatedBy.user.ipAddress)
| sort by TimeGenerated desc

Any MFA method registered from an IP other than the user’s known IPs or during the compromise window must be flagged for removal during containment. This is a CRITICAL containment action — leaving a fraudulently registered MFA method in place means the attacker can re-enter the environment after every other containment action (password reset, session revocation) is complete.

Persistent but finite cloud evidence

These evidence categories are retained by Microsoft for a defined period. They are not at risk of immediate loss, but the triage responder should snapshot the relevant entries to the case folder to ensure the investigation has the data regardless of future retention expiry.

Sign-in logs. Retained for 30 days natively in Entra ID (P1/P2 licence). If streamed to Sentinel, retained per workspace configuration (30 days to 2 years). The triage responder does not need to rush to capture sign-in logs — but should export the relevant entries (affected user, last 48 hours, all IPs) to the IR case folder as a snapshot. This ensures the investigation team has the data even if retention expires before the investigation completes.

Unified audit log. Retained for 90 days (standard M365) or 1 year (E5). Contains Exchange Online, SharePoint, OneDrive, Teams, and Entra ID activity in a single log. The triage responder should capture the entries for the affected user and relevant time window — but this is a “snapshot during triage” action, not a “capture now or lose it” action.

Mailbox audit logs. Retained for 90 days by default. Contains: MailItemsAccessed (which emails the attacker read), Send (emails sent as the user), MoveToDeletedItems, SoftDelete. The triage responder should snapshot the mailbox audit entries for the affected user during the compromise window to ensure the investigation can determine what the attacker accessed.

Retention awareness: the cloud evidence calendar

Cloud evidence has CALENDAR-based volatility — not event-based. Unlike endpoint evidence (which degrades when the system reboots or processes terminate), cloud evidence degrades when calendar-based retention windows expire. The triage responder must maintain awareness of these retention windows to understand which evidence is currently available and which will expire soon.

The M365 retention calendar for triage:

Entra ID sign-in logs: 30 days from the sign-in event. An incident discovered on day 25 has 5 days of remaining sign-in data. An incident discovered on day 31 has ZERO sign-in data (unless ingested into Sentinel).

Entra ID audit logs: 30 days from the audit event. Covers directory changes, application consent, role assignments, and group modifications.

Microsoft 365 unified audit log: 90 days (E3), 180 days (E5 since 2024 update), or 365 days (E5 with Audit Standard), or 10 years (Audit Premium). The unified audit log is the broadest M365 evidence source — covering Exchange, SharePoint, OneDrive, Teams, Power Platform, and Entra ID operations. The retention tier determines the investigation lookback window.

Mailbox audit log: 90 days default. Contains MailItemsAccessed, Send, MoveToDeletedItems, SoftDelete, and HardDelete operations per mailbox. This is the evidence that shows what the attacker read, sent, and deleted in the compromised mailbox.

Defender for Office 365 real-time detections: 30 days. Contains email threat detection events — phishing detected, malware blocked, URL detonation results.

Message trace: 10 days for the quick message trace in the Exchange admin centre. 90 days for the historical message trace (requires report submission, results delivered asynchronously). Message trace shows the delivery path and status of every email — useful for determining whether a BEC email was delivered, bounced, or quarantined.

SharePoint and OneDrive file version history: 30,000 versions or 60 days (whichever is reached first, configurable per library). File version history shows what the attacker modified or uploaded — but old versions may be purged before the investigation team accesses them.

The Sentinel retention layer:

When M365 data is ingested into Sentinel, the retention extends beyond the native M365 limits. Sentinel interactive retention: configurable from 30 days to 2 years per table. Sentinel archive tier: up to 12 years of total retention (interactive + archive). The archive tier is searchable via search jobs (which take minutes to hours to complete, not real-time queries).

The triage responder’s snapshot (exporting relevant log entries to the case folder during triage) provides a THIRD retention layer that is independent of both M365 native retention and Sentinel retention. Even if the M365 retention expires and the Sentinel workspace retention is reduced, the snapshot in the case folder preserves the evidence permanently.

The practical implication for triage:

When the triage responder opens a cloud identity alert, the FIRST check should be: how old is this alert? If the alert references activity from 28 days ago, the Entra ID sign-in log entries for that activity expire in 2 days. The triage responder should snapshot the relevant sign-in entries BEFORE running any analysis — preserving the data against imminent expiry. If the alert references activity from 2 hours ago, there is no retention urgency — the data will be available for 30 days.

At NE, Rachel implemented a triage automation rule that adds a comment to every incident: “Earliest event timestamp: [X]. Sign-in log retention remaining: [30 - age in days] days. Snapshot urgency: [HIGH if <5 days remaining, NORMAL otherwise].” This automation ensures the analyst knows the evidence window before they begin triage — preventing the scenario where an analyst spends 10 minutes triaging an alert only to discover that the critical sign-in data expired yesterday.

The cloud triage preservation sequence

The 5-minute cloud evidence preservation sequence for any compromised M365 identity:

Minute 0-1: Run the active sessions query. Identify suspicious sessions. Revoke all sessions if any suspicious session is confirmed.

Minute 1-2: Run the OAuth consent grants query. Identify and flag any grants from suspicious IPs or during the compromise window. Revoke malicious grants.

Minute 2-3: Run the inbox rules query. Identify and document any rules created during the compromise window. Do not delete yet — document first (evidence), then delete as containment.

Minute 3-4: Run the MFA registration query. Identify any methods registered from suspicious IPs. Flag for removal during containment.

Minute 4-5: Export sign-in logs and audit logs for the affected user (last 48 hours) to the IR case folder. This is the snapshot that ensures the investigation team has complete cloud evidence regardless of future retention.

This 5-minute sequence captures all time-sensitive cloud evidence and initiates the critical containment actions. The investigation team receives the preserved evidence and the containment status. They begin deep analysis — mailbox content review, full scope assessment, regulatory impact evaluation — from the triage responder’s handoff.

The MailItemsAccessed evidence gap

MailItemsAccessed is the single most important mailbox audit event for triage — it tells the investigation team which emails the attacker read. But MailItemsAccessed has a significant evidence gap: it requires an E5 licence (or Microsoft 365 E5 Compliance add-on). Organisations with E3 licences do not have MailItemsAccessed logging enabled. The triage responder must know whether the organisation’s licensing supports this event BEFORE the incident — discovering during triage that the critical evidence source does not exist wastes minutes on queries that return zero results.

Checking MailItemsAccessed availability:

1
2
3
4
5

// Verify MailItemsAccessed is being logged
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation == "MailItemsAccessed"
| take 1

If this returns zero results: MailItemsAccessed is not enabled. The triage responder must use alternative evidence to assess mailbox access: MailboxLogin events (which show WHEN the attacker logged into the mailbox but not WHICH emails they read), and MessageBind events (legacy Exchange operations that capture some read activity). These alternatives provide less granular evidence but are available on all licence tiers.

At NE (E5 licence), MailItemsAccessed is fully enabled. Query 5 of the triage pack returned 47 MailItemsAccessed events for the CHAIN-HARVEST compromise — identifying that the attacker read 47 emails from the CEO’s mailbox, including 12 containing financial information. Without MailItemsAccessed, the investigation team would have known the attacker accessed the mailbox but not which specific emails were read — making the data exposure assessment significantly harder and the regulatory notification less precise.

The licensing check should be part of triage PREPARATION, not triage execution. Run the verification query during normal operations and document the result: “MailItemsAccessed: ENABLED” or “MailItemsAccessed: NOT AVAILABLE (E3 licence). Use MailboxLogin + MessageBind as alternatives.” This documentation saves 2 minutes during every cloud triage by eliminating a query that would return zero results.

Troubleshooting

“The AuditLogs query returns zero results for OAuth consent grants.” Verify that the Entra ID connector is enabled in Sentinel and that AuditLogs are being ingested. Check the workspace’s data tables: AuditLogs | take 1. If the table is empty, the connector is not configured. If the table has data but your query returns zero, the affected user may not have any consent grants — which is actually good news for the triage.

“I revoked sessions but the attacker is still active.” Check for refresh tokens, OAuth grants, and MFA registrations — all three provide re-authentication paths that survive session revocation. Also check whether the attacker has access to the user’s endpoint (CHAIN-HARVEST extended scenario from TR0.4) — endpoint compromise provides a credential source that cloud-only containment does not address.