TR1.2 Cloud Evidence Volatility

The cloud volatility paradox

Cloud evidence is simultaneously more persistent and more fragile than endpoint evidence. A sign-in log entry survives for 30 days on P1/P2 licensing — far longer than a network connection that closes in seconds. But the configurations an attacker changes — OAuth consent grants, inbox rules, MFA registrations, mailbox delegate permissions — can be reversed by the attacker at any time to cover their tracks. The retention of the log that records the change is not the same as the persistence of the change itself.

This paradox creates two categories of triage urgency. Evidence that decays on a known schedule — sign-in logs, audit log entries, mailbox audit records — needs to be snapshotted during triage but won't disappear in the next hour. Evidence that the attacker can actively destroy — OAuth grants they revoke, inbox rules they delete, MFA methods they deregister — must be captured immediately because the attacker controls the timeline, not Microsoft's retention policy.

Figure TR1.2 — Cloud evidence in three volatility categories. Left: attacker-controlled artifacts that must be captured during triage. Center: retention-controlled logs that need snapshotting. Right: long-retention data the investigation team collects later.

Attacker-controlled evidence: capture first

Session tokens, OAuth grants, inbox rules, and MFA registrations are the highest-priority cloud evidence because the attacker can remove them at any time. Session revocation by the triage responder eliminates the active session — but the attacker who registered a fraudulent MFA method can re-authenticate with a new session immediately after revocation. The responder who revokes the session without first documenting the OAuth grants, inbox rules, and MFA methods has closed one door while three others remain open.

The triage sequence for attacker-controlled evidence follows a specific order. First, query and document — don't modify yet. Capture the current state of all four persistence mechanisms before changing anything. Second, photograph the threat. Third, contain it. If you revoke the session before documenting the OAuth grants, the session revocation generates new audit log entries that may push older entries closer to their retention boundary.

More importantly, a sophisticated attacker monitoring their own session state may react to revocation by cleaning up their persistence mechanisms — deleting inbox rules, revoking their own OAuth grants — which destroys the evidence of what they set up.

Here's what a suspicious sign-in record looks like in Sentinel. The analyst reads this raw evidence before running any enrichment queries.

{
  "TimeGenerated": "2026-05-18T02:17:43Z",
  "UserPrincipalName": "svc-backup@northgateeng.com",
  "IPAddress": "185.220.101.34",
  "Location": { "city": "Frankfurt", "countryOrRegion": "DE" },
  "AppDisplayName": "Azure Portal",
  "ResourceDisplayName": "Windows Azure Service Management API",
  "ResultType": "0",
  "AuthenticationMethodsUsed": ["password"],
  "ConditionalAccessStatus": "notApplied",
  "DeviceDetail": { "operatingSystem": "Linux", "browser": "Firefox 128.0" },
  "RiskLevelDuringSignIn": "none",
  "TokenIssuerType": "AzureAD",
  "IsInteractive": true
}

Read this record the way the triage analyst does. The service account svc-backup authenticated interactively from a Frankfurt IP address using only a password — no MFA. The device is running Linux with Firefox, which is unusual for a backup service account that should be authenticating non-interactively from an Azure automation context. Conditional access status shows "notApplied," meaning no CA policy evaluated this sign-in.

Risk level is "none" because Microsoft's identity protection had no signal to flag it — the attacker used a clean IP that hadn't appeared in previous attacks. Every field in this record is a triage decision point, and every field will be unavailable 30 days from now on P1/P2 licensing without Diagnostic Settings routing to Log Analytics.

Retention boundaries the responder must know

The retention timelines for cloud evidence are licensing-dependent, and most organizations discover their actual retention only during an incident. Entra ID sign-in logs retain for 7 days on the Free tier and 30 days on P1/P2. Entra audit logs follow the same schedule. Neither extends automatically — the organization must configure Diagnostic Settings to route these logs to a Log Analytics workspace for longer retention.

The Unified Audit Log (UAL) in Microsoft 365 follows a different retention model entirely. As of late 2023, Microsoft increased the default Audit Standard retention from 90 to 180 days for all license tiers. Organizations with E5 licensing (or Purview Audit Premium) retain UAL entries for one year by default for Exchange, SharePoint, OneDrive, and Entra activity. Custom retention policies can extend this to 10 years with an additional add-on license.

The retention is determined by the license assigned to the user who generated the activity, not the administrator searching the logs.

That licensing detail has a practical consequence for triage. If the compromised account is a service account on an E3 license but the security team has E5 licenses, the service account's UAL entries are retained for 180 days — not the one-year default the security team might expect from their own accounts. The triage responder who assumes "we have E5, so we get a year" without checking the specific account's license will miscalculate the evidence window.

The retention check is per-user, and the user that matters is the one the attacker compromised.

// Triage query: all sessions for the affected account in the last 24 hours
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName == "svc-backup@northgateeng.com"
| where ResultType == "0"
| project TimeGenerated, IPAddress,
    City = tostring(LocationDetails.city),
    App = AppDisplayName,
    Device = tostring(DeviceDetail.operatingSystem),
    Browser = tostring(DeviceDetail.browser),
    CAStatus = ConditionalAccessStatus,
    MFA = AuthenticationRequirement
| sort by TimeGenerated desc

This query returns every successful authentication for the compromised account in the last 24 hours. The columns are chosen for triage speed: IP and city identify where the sessions originated, App tells you what the attacker accessed, Device and Browser reveal the platform, CAStatus shows whether conditional access evaluated the sign-in, and MFA shows whether multi-factor was required. If the account is a service account that should only authenticate non-interactively from Azure, every row with IsInteractive: true and an external IP is suspicious.

The query window matters. Twenty-four hours captures the immediate attack timeline. But if the incident was detected days after initial access — common for BEC campaigns — the analyst needs to extend the window. At that point, retention becomes the constraint. With 30 days of native sign-in data, an incident discovered on day 28 leaves two days of searchable history.

An incident discovered on day 31 has zero native sign-in data available unless Diagnostic Settings were configured to forward logs to Log Analytics before the incident occurred.

OAuth consent grants and the persistence problem

OAuth consent grants are the cloud persistence mechanism that session revocation doesn't touch. When the attacker grants consent to a malicious application — typically disguised as a legitimate tool like "Azure Backup Utility" or "Microsoft Security Scanner" — the application receives its own access and refresh tokens. These tokens refresh independently of the user's session. Revoking the user's session, resetting their password, and even removing their MFA methods does not affect the OAuth application's access.

The application continues reading mail, accessing files, and sending messages until its consent grant is explicitly revoked.

The triage action is to query audit logs for consent events by the compromised account, document every grant, and then revoke the malicious ones. The documentation step is essential because once revoked, the consent grant no longer appears in the active permissions list. If the analyst revokes first and documents second, the evidence of what the attacker's application had access to is gone — replaced by the absence of a permission that the investigation team can't reconstruct.

Inbox rules operate on the same principle. The attacker creates a rule to forward financial emails to an external address or to move security notifications to a hidden folder. The rule operates continuously, independent of whether the attacker is actively logged in. If the attacker realizes their session has been revoked, they may log back in through a persistent mechanism (fraudulent MFA, OAuth grant) and delete the rule to cover their tracks.

The triage responder who documented the rule before containment has the evidence. The responder who contained first has nothing.

The MailItemsAccessed evidence gap

MailItemsAccessed is the single most important mailbox audit event for BEC triage — it records which specific emails the attacker opened and read. Without it, the investigation team knows the attacker accessed the mailbox but cannot determine which messages they viewed, which makes the data exposure assessment imprecise and the regulatory notification vague.

MailItemsAccessed requires E5 licensing or the Microsoft Purview Audit Premium add-on. Organizations on E3 do not have this event available. The triage responder must know the organization's licensing tier before the incident — discovering during triage that the critical evidence source doesn't exist wastes minutes running queries that return zero results. The licensing check should be part of triage preparation: run the verification query during normal operations and document the result.

If MailItemsAccessed is unavailable, the alternatives are MailboxLogin events (when the attacker logged in, but not what they read) and MessageBind events (partial read activity from legacy Exchange operations).

After checking attacker-controlled artifacts and running the session enrichment queries, the analyst documents the triage findings. This incident comment records the cloud evidence state at the point of triage — what was captured, what was found, and what containment actions were taken.

This comment serves two audiences. The immediate audience is the investigation team who will pick up the case from this triage handoff. The long-term audience is the legal or compliance team who may need to reconstruct the response timeline months later. The retention note at the bottom is the detail that distinguishes a senior triage responder from a junior one — it tells the investigation team exactly how long they have before the native evidence expires and whether extended retention via Sentinel provides a backstop.