What should I do if I suspect an active cloud compromise?¶

Treat an active cloud compromise as two problems at once: continuing harm must be stopped, and changing cloud records must be preserved. The balance depends on urgency. Protecting a victim or critical service may require immediate containment, but every intervention should be timed and recorded because it changes the evidential picture.

Establish the live scope¶

Identify the affected account, tenant or workspace and what the suspected access can currently reach. Include linked identity providers, recovery accounts, connected applications and administrator roles; compromise of one central identity may open several services.

Clarify the immediate risk:

• Is data being viewed, removed, altered or shared?
• Are victims, funds, communications or essential services at continuing risk?
• Does the access have administrator authority?
• Are other accounts, devices or organisations connected?
• Which logs or settings are liable to change or expire?

This is enough to frame the response without first solving personal attribution.

Preserve the state that containment will change¶

Where urgency permits, capture the current access routes and export available authentication, session, application-consent, security-change and audit records. Preserve provider alerts in their original form, including event identifiers, timestamps, time zones and collection source.

Record active sessions, tokens, registered devices, recovery methods, users, roles, API credentials, forwarding rules and shared links. A screenshot may show the visible state, but a provider export or audit event is usually needed to preserve identifiers and history. Consider a formal cloud-data preservation request where provider-held material may otherwise be lost.

Do not use recovered passwords, session tokens or live links to explore an account without the necessary authority and specialist support. Ordinary interaction can create events, trigger synchronisation or alert the intruder.

Contain the access route, not only the password¶

A password change may be necessary, but it may not revoke existing cloud sessions or remove attacker-controlled applications, recovery methods and identities. Containment may therefore require coordinated revocation of sessions and tokens, removal of malicious consent, disabling of added accounts, restoration of security settings and protection of the identity provider.

Cloud persistence explains why each surviving authority must be mapped. Confirm ownership and purpose before removing unfamiliar service accounts or integrations: legitimate automation can look unusual and its sudden removal may cause further harm.

Make the response part of the timeline¶

Keep a simple intervention record:

Time	Action	Expected effect	Observed result
14:12 UTC	Sessions revoked	Existing web sessions should end	Session SES-41C2 records no later activity
14:18 UTC	Application consent removed	Application token should lose authority	API requests rejected from 14:19 UTC
14:24 UTC	Password and MFA reset	Original credentials replaced	Known user re-enrolled on managed device

This separates attacker activity from defender activity and shows which routes should have stopped. Continued events after an intervention may reveal an uncontained route rather than a failed password change.