How to Revoke Cloud Sessions, App Access, and Shared Links After a Security Incident

Overview

Post-incident cleanup in cloud storage usually has three separate jobs: end active access, remove delegated access, and cut off accidental sharing. Many users do only one of these. They change a password, feel safer, and move on. But if a malicious app still has an OAuth token, if a shared folder link is still public, or if another signed-in device remains trusted, the account may still be exposed.

A practical response sequence looks like this:

1. Contain: revoke cloud sessions, sign out unknown devices, and pause risky syncing if needed.
2. Reduce delegated access: remove suspicious connected apps, browser extensions, and integrations.
3. Shut down exposure paths: disable shared links, review folder permissions, and check external collaborators.
4. Secure the identity layer: change passwords, rotate recovery options, review MFA, and verify account recovery contacts.
5. Assess file impact: look for deleted, overwritten, encrypted, or newly shared files.
6. Document what changed: keep a short incident note so you can revisit the same checklist later.

This order is useful because it prioritizes access control before cleanup. In a real incident, especially after a Dropbox scam email, OneDrive phishing message, or fake Google Drive email, your first goal is not to investigate every detail. It is to stop further account activity.

If you are also dealing with missing or altered files, pair this article with your platform-specific recovery process. For related recovery steps, see How to Recover Overwritten Files in Google Drive, Dropbox, and OneDrive and the broader guides for Google Workspace and Microsoft 365 linked below.

Checklist by scenario

Use the scenario that best matches what happened. If you are unsure, start with the first checklist and complete all high-priority steps.

Scenario 1: You clicked a suspicious cloud-sharing email or link

This is the most common starting point for a file sharing scam. Even if you did not enter credentials, treat the event as potentially meaningful if the page loaded, asked for login, downloaded a file, or prompted you to approve access.

• Disconnect first: close the page and stop interacting with the message.
• Check the URL you visited: document the domain for later review, but do not revisit it casually. If you need a verification framework, use Suspicious File Sharing Link Checker: What to Verify Before You Click.
• Revoke cloud sessions: sign out of all sessions or at minimum all unfamiliar devices. This is the fastest broad containment step.
• Change the account password: use a unique password not used anywhere else.
• Review MFA: make sure multi-factor authentication is enabled and that backup codes, authenticator enrollment, and phone numbers are still yours.
• Remove app access: review connected apps and remove anything unfamiliar or unnecessary. This is especially important if the phishing page requested permissions instead of a password. For example, users often need to remove app access Google Drive after an OAuth consent screen attack.
• Disable shared links after phishing: review recently shared files, folders, and links. Remove public or broad-access links you do not actively need.
• Search recent activity: look for mass downloads, permission changes, newly created forwarding rules, or file deletions.

If the suspicious message looked like a platform notice, compare it against a legitimacy checklist before interacting further: How to Check Whether a Cloud Storage Email Is Legitimate.

Scenario 2: You entered your password on a phishing page

If you typed your password, assume the account may already be in use by someone else. Act as if timing is critical.

1. Change the password immediately from a clean session you trust.
2. Revoke all sessions across the cloud platform and, where possible, the broader identity account.
3. Review recovery email, phone, and security questions so an attacker cannot reset access later.
4. Remove unknown app grants and add-ins.
5. Review inbox and rules if the cloud account is tied to email. Attackers often create forwarding rules to hide alerts.
6. Inspect shared links and collaborators.
7. Check deleted and overwritten files.

This is where account takeover recovery becomes more than a login problem. A compromised identity can also affect cloud permissions, sync clients, document ownership, and collaboration settings.

Scenario 3: You approved a third-party app or extension

Consent-based attacks are easy to underestimate because the attacker may never need your password. A granted app token can continue working until you revoke it.

• Open the platform's connected apps or security permissions page.
• Remove any app you do not recognize.
• Remove any app you recognize but no longer need. Old integrations are a quiet source of risk.
• Check scope, if shown. Read whether the app had read-only access, full file access, sharing controls, or offline access.
• Review browser extensions that touch webmail, cloud drives, document signing, or download helpers.
• Rotate password and revoke sessions anyway if you are uncertain whether credentials were also exposed.

This is a high-value control because delegated access can survive ordinary password changes on some platforms or workflows. Removing the app token closes a path that many users forget to inspect.

Scenario 4: A file or folder was unexpectedly shared

Unexpected sharing may indicate a compromised account, an overbroad sharing setting, a sync-side mistake, or simple collaborator confusion. The response should still be structured.

• Identify the object: file, folder, shared drive, team folder, or external collaboration space.
• Disable broad links: turn off anyone-with-link access where possible.
• Reduce permissions: move from edit to view, or from public to invited users only.
• Review inherited permissions: sometimes the issue is the parent folder, not the file.
• Check link creation history and recent activity.
• Confirm whether sync clients propagated the same item elsewhere.

For a broader review pattern, see Cloud Storage Security Checklist for Shared Files and External Links.

Scenario 5: Your device was stolen, left unlocked, or used by someone else

In this case, the session itself may be the problem. If the browser was signed in, the cloud account may already be open to the next person who touches the device.

• Revoke cloud sessions and sign out remote devices.
• Invalidate local trust where possible: remove the device from trusted devices lists.
• Pause or disconnect sync clients if you suspect local tampering.
• Change the account password and review MFA enrollment.
• Check recent downloads and exports.
• Review shared links and recently opened files.

If the device was managed by your organization, also follow local endpoint response rules. Cloud containment helps, but it does not replace device-level triage.

Scenario 6: You suspect an admin or team-space issue

For administrators, the concern is wider than one user account. A single compromise can affect shared drives, SharePoint libraries, team folders, and delegated admin access.

• Revoke the user session and reset identity controls.
• Review admin roles and delegated roles.
• Check external sharing settings at tenant or workspace level.
• Audit app consents, service accounts, and automation tokens.
• Inspect retention, trash, and version history before making destructive changes.

For file impact review, see Microsoft 365 File Recovery Guide for Admins: OneDrive, SharePoint, and Recycle Bin Paths and Google Workspace Admin Guide to Recovering User Files and Shared Drive Content.

What to double-check

Once immediate containment is done, slow down and verify the details that commonly get missed.

1. Active sessions versus trusted devices

Signing out sessions may not remove a device from every trust list. Review both. If your platform separates browser sessions, mobile sessions, and remembered devices, inspect each one.

2. App access versus password resets

A password change is necessary but may not be sufficient. Confirm that suspicious app tokens, API keys, extensions, and connected services were actually removed. This is one of the most important checks after cloud-related phishing.

3. Shared links versus direct collaborators

Users often disable a public link and assume the file is private again. But direct user permissions may still remain. Review both link-based access and named-user access. If the file lives in a shared parent folder, check inheritance too.

4. Sync behavior

If ransomware, accidental deletion, or unauthorized edits touched a synced folder, changes may have propagated quickly. Before large-scale cleanup, review version history, recycle bins, and restore options. Helpful references include Box File Recovery Guide: Deleted Files, Version History, and Admin Restore Options and iCloud Drive File Recovery: Deleted Files, Recently Deleted, and Restore Limits.

5. Evidence you may need later

Take screenshots or notes of suspicious app names, unfamiliar devices, modified settings, and timestamps before removing them if that is consistent with your environment. For individual users, a simple note is enough. For admins, preserve an incident trail that explains what was revoked, when, and why.

6. Recovery paths

If files were deleted or overwritten, review native restore options before uploading them to third-party tools. If you do consider external recovery utilities, vet them carefully: Safe File Recovery Tools: How to Vet Software Before Uploading or Scanning a File and Best Cloud File Recovery Tools and Services: Features, Limits, and Privacy Tradeoffs.

7. Identity impact outside cloud storage

If the same identity is used for email, chat, SSO, or productivity tools, expand the review. A stolen session in one place can expose notifications, approvals, and recovery prompts in another. This is also where identity theft after phishing starts to become a realistic concern, especially if personal data or tax, payroll, or HR documents were exposed.

Common mistakes

The goal here is not perfection. It is to avoid the cleanup errors that leave the door open.

• Changing the password but not revoking sessions. Existing sessions may continue briefly or remain trusted depending on platform behavior.
• Ignoring third-party app grants. OAuth-style access is one of the easiest things to forget.
• Disabling one link but not reviewing the whole folder. Exposure often sits at the parent level.
• Deleting evidence too quickly. Remove access, but record what you found first if possible.
• Skipping MFA review. If an attacker added their own factor or changed recovery details, your new password may not be enough.
• Assuming nothing happened because no files look missing. Quiet data access can matter as much as deletion.
• Using random recovery software too early. Native cloud recovery features are often the safer first step.
• Not checking suspicious URLs carefully. Small domain variations and lookalike login pages are central to many Google Drive scam alert and file-share lures.

A good rule is simple: after any cloud incident, review access at three layers—identity, app delegation, and file sharing. If one of those layers is untouched, your response is probably incomplete.

When to revisit

This checklist is most useful when you return to it before the next scare, not only after one. Revisit it whenever your tools, users, or collaboration patterns change.

• Before seasonal planning cycles: audit shared links, old collaborators, and stale app grants before holidays, fiscal year-end work, or project transitions.
• When workflows or tools change: any new signing app, CRM connector, AI assistant, browser extension, or file request workflow should trigger a fresh review.
• After a phishing drill or real incident: update your own runbook based on what took too long or was hard to find.
• When staff or contractors leave: review inherited folders, externally shared links, and delegated app access.
• When you rely more heavily on sync: increased sync usage changes the risk profile for deletions, overwrites, and ransomware propagation.

For a practical recurring routine, keep a short personal or team checklist:

1. List where you revoke sessions for each major platform.
2. List where you review connected apps and extensions.
3. List where you disable public links and inspect external collaborators.
4. List where you check recent activity and restore deleted files.
5. Store those notes somewhere you can reach during an incident.

If you want one takeaway to keep, make it this: revoke sessions, remove app access, and disable shared links as a single containment bundle. That pattern works whether you are responding to a suspicious email, a stolen laptop, a reused password, or a broad cloud-sharing mistake. It is also the kind of checklist worth revisiting every time your environment changes, because the exact menu names may move, but the recovery logic stays the same.