What evidence might show that a cloud account was taken over?¶

A cloud-account takeover is best supported by a connected sequence: an access route the genuine user did not authorise, a session created through that route, and activity or security changes that the user cannot credibly explain. One unfamiliar IP address is only an indicator; several independent records describing the same sequence can be strong evidence of compromise.

Build the conclusion event by event¶

Signs of unauthorised access become more persuasive when they can be joined by stable identifiers and close timing. The useful chain may include:

• a phishing message, deceptive MFA prompt, recovery event or malicious application consent;
• authentication from a new device, network or application;
• creation of a cloud session or issue of a token;
• changes to recovery details, authentication methods, permissions or forwarding;
• access, download, deletion or sharing inconsistent with the account's normal use; and
• the genuine user's report, device state and response to provider alerts.

The question is not how many warning signs exist. It is whether the records can connect the entry, continuing authority and resulting activity.

A short sequence is more useful than a list of anomalies¶

Dave's Microsoft 365 account records a successful sign-in from a new Edge browser at 09:08 and session SES-41C2. Three minutes later the recovery telephone number changes. The same session context is then associated with 186 downloads from OneDrive folder F-2804 and creation of a public link. At 09:31 Dave reports repeated MFA prompts from his known Surface Laptop and rejects the new recovery number.

The provider records connect one session context with the security changes and data activity. Evidence from Dave's known device challenges the innocent explanation. The next useful comparison is SES-41C2's sign-in detail, the recovery-change audit event, the OneDrive operations and Dave's device/browser history - not merely the alert label.

Use different evidence sources for different propositions¶

Provider authentication and audit logs can show what the service accepted and what an account, session or application did. Device evidence may show the phishing route, malware, browser state, possession of a known device or the user's response to prompts. Communications and business records may test whether an unusual download, administrator action or journey was legitimate.

Normal use must be considered, particularly shared accounts, travel, VPNs, administrators and automation. The explanation should be tested against the precise event rather than accepted merely because it is possible.

Keep takeover and attacker identity separate¶

Established: the evidence may establish that the provider accepted unauthorised access and that the resulting session changed security settings or handled data.

Still open: who controlled the remote device, how the access route was obtained and whether that person is responsible for the wider conduct.

Activity after a password reset may indicate cloud persistence, but it may also come from a legitimate surviving session or application. Map the exact authority used before attributing it to the intruder.