Traditional ransomware encrypts files on local disks. Modern ransomware operators have adapted to target cloud infrastructure — Microsoft 365, SharePoint, OneDrive, AWS S3, Google Workspace — where organizations store their most critical data. Cloud ransomware exploits the same administrative access organizations trust for legitimate operations.
How Cloud Ransomware Works
Microsoft 365 / SharePoint Attack Chain
- Initial access: phishing attack steals admin or Global Admin credentials, or OAuth token theft via a malicious app
- Persistence: attacker registers a malicious OAuth app with
Sites.ReadWrite.Allpermissions - Reconnaissance: enumerate SharePoint sites, OneDrive accounts, Teams channels
- Encryption: use the SharePoint/OneDrive API to replace files with encrypted versions OR enable ransomware-as-a-service tooling that calls Microsoft Graph API at scale
- Deletion of backups: disable version history, delete previous versions, remove Recycle Bin items
The key abuse: Microsoft 365 APIs don’t distinguish between a legitimate admin operation and a malicious one if the credentials are valid.
December 2023: Proofpoint researchers demonstrated a technique using Microsoft 365’s “AutoSave” and version history features — an attacker with edit access to SharePoint can reduce version history to 1, overwrite all files, effectively making recovery impossible.
AWS S3 Ransomware
Documented attacks (starting 2022):
- Attacker obtains AWS credentials (from code repos, Lambda environment variables, SSRF exploitation)
- Creates a new CMK (Customer Managed Key) in KMS
- Re-encrypts all S3 objects using the new key
- Deletes the KMS key — data becomes permanently inaccessible
- Leaves ransom note in S3
Amazon can sometimes recover deleted KMS keys within a short window, but not always.
Google Workspace
Similar attack surface:
- Admin account takeover enables mass deletion/encryption of Drive files
- Malicious OAuth apps can read, modify, and delete files
- Calendar data, email, and shared drives all targetable
Why Cloud Ransomware Is Particularly Dangerous
- No traditional antivirus coverage: files encrypted via API, not local disk writes
- Bypasses backup solutions that sync with cloud storage — backups reflect the encrypted state
- Weaponizes legitimate APIs: indistinguishable from admin activity without behavioral analysis
- Scale: one compromised admin account → entire organization’s data
- Version history bypass: most cloud users don’t realize version limits can be changed
Detection
Microsoft 365 Indicators
Unusual OAuth app consent events
OAuth apps with Files.ReadWrite, Sites.ReadWrite permissions
Mass file update events (thousands of files changed in minutes)
Version history configuration changes
Large-scale Recycle Bin emptying
Multiple geographic login anomalies on admin accounts
Microsoft Sentinel detections:
SecurityAlert | where AlertName == "Mass file sharing"- Monitor
AzureActivityfor bulk KMS key deletion (AWS equivalent)
AWS Indicators
CloudTrail: DeleteObject/PutObject in bulk
CloudTrail: GenerateDataKey followed by PutObject on all S3 objects
CloudTrail: ScheduleKeyDeletion or DisableKey for CMKs
IAM: new access keys created, policies attached to unusual roles
Set CloudTrail alerts for KMS key scheduling deletion:
# AWS Config rule for KMS key deletion
{
"source": {"owner": "CUSTOM_LAMBDA", "sourceIdentifier": "LAMBDA_ARN"},
"scope": {"complianceResourceTypes": ["AWS::KMS::Key"]},
"configRuleState": "ACTIVE"
}
Prevention
Microsoft 365
- MFA for all accounts, especially Global Admin: block the initial credential theft
- Privileged Identity Management (PIM): require justification and approval for admin roles, time-limit access
- Conditional Access Policies: block unusual sign-in locations, require compliant devices
- App consent policies: disable user ability to consent to 3rd-party apps; require admin approval
- Retention policies: use Microsoft Purview retention policies that can’t be deleted by regular admins
- Microsoft 365 Backup: Microsoft’s dedicated backup product (launched 2023) provides admin-controlled backup separate from OneDrive sync
AWS S3
# Enable MFA Delete on S3 buckets (requires MFA to delete objects or versions)
aws s3api put-bucket-versioning \
--bucket mybucket \
--versioning-configuration Status=Enabled,MFADelete=Enabled \
--mfa "arn:aws:iam::account-id:mfa/device TOTP-CODE"
# S3 Object Lock (WORM - Write Once Read Many)
aws s3api put-object-lock-configuration \
--bucket mybucket \
--object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Days": 30}}}'
# Prevent KMS key deletion without approval
# Add a CloudTrail + Lambda + SNS pipeline that alerts and optionally cancels key deletion
Universal Controls
- Immutable backups: use backup solutions that create immutable copies (AWS Backup with WORM lock, Veeam Immutable Backups)
- Principle of least privilege: no user needs write access to everything
- Break-glass accounts: admin accounts with physical MFA tokens stored in a safe, not used daily
- Monitor third-party OAuth apps: audit all apps with access to your tenant quarterly
Incident Response
If cloud ransomware hits:
- Isolate: revoke compromised credentials immediately, disable the malicious OAuth app
- Preserve: take snapshots, enable additional logging before further investigation
- Assess: determine scope — which accounts, which files, time window of encryption
- Recover: check version history before deletion, check Microsoft retention policies, engage Microsoft or AWS support for emergency key recovery
- Report: ransomware impacting cloud data may trigger breach notification requirements in your jurisdiction
Cloud ransomware recovery is often only possible if versioning and immutable backup were configured before the attack. Organizations that discover exposure after the fact have few options — prevention is the only reliable defense.