A team of Proofpoint researchers say they have discovered potentially dangerous standard functionality in Microsoft Office 365 that could allow ransomware to encrypt files stored in SharePoint and OneDrive in such a way that they become completely unrecoverable without dedicated backups or a decryption key.
The team – Or Safran, David Krispin, Assaf Friedman and Saikrishna Chavali – wanted to look at two of the more widely used enterprise cloud apps within the Microsoft 365 and Office 365 suites to demonstrate that ransomware operators can now target data held in the cloud, and launch attacks on cloud infrastructure.
“Ransomware attacks have traditionally targeted data across endpoints or network drives,” they said in a disclosure blog published today. “Until now, IT and security teams felt that cloud drives would be more resilient to ransomware attacks.
“After all, the now-familiar ‘AutoSave’ feature, along with versioning and the good old recycle bin for files, should have been sufficient as backups. However, that may not be the case for much longer.”
The possible attack chain works as follows – note that it can be automated using Microsoft APIs, command line interface (CLI) scripts and PowerShell scripts.
First, attackers need to gain access to one or more user’s SharePoint Online or OneDrive accounts by compromising or hijacking their identities.
They then have access to any file owned by the compromised user or controlled by the third-party OAuth application – this would include user’s OneDrive account.
The third step is to reduce the versioning limit of files to a low number (such as one) and encrypt the file more times than the versioning limit (say twice, to keep it simple). This step would be unique to cloud ransomware compared to the attack chain for an endpoint-based version. Note that at this point, an attacker could also exfiltrate the unencrypted files to leak or sell on in a double extortion hit.
Finally, now that all original versions of the files are lost, leaving only the encrypted versions of each file in the cloud account, the attacker can demand a ransom.
The third step in the chain is what would make this type of attack viable, and it hinges on functionality unique to Microsoft environments, said Proofpoint.
It works like this, the team explained: every document library contained within SharePoint Online or OneDrive will have a user-configurable setting for the number or saved versions, which the owner can change regardless of their other roles, ie they don’t need admin rights. This setting can be found within the versioning settings under list settings in each library.
By design, if the user reduces the library version limit, any further changes made to the files contained within result in older versions becoming very hard to restore.
There are two ways to abuse this maliciously, either by making too many versions of a file or reducing the version limits.
In the first instance, because most OneDrive accounts have a default version limit of 500, someone could edit files 501 times, so that the original version is 501 versions old and therefore no longer restorable. They could then encrypt the 500 restorable versions.
But this is quite complex and requires more time, scripting and machine resources, and is probably easier for defenders to spot, so Proofpoint’s team suggests the second tactic is more likely.
So, if they reduce the library versioning number to one, only the most recent version of the file before the last edit is saved and restorable. Therefore, by editing the file twice, either encrypting it twice or making changes to its content or metadata then encrypting it, an attacker can ensure an organisation is unable to restore the original version without the decryption key.
Incidentally, setting the version limit to zero would be a red herring and won’t delete the versions, which will be available to the user by resetting the limit – or they could try turning it off and on again.
Fortunately, said Proofpoint, standard best-practice recommendations for regular ransomware protection will also apply. Defenders should make sure that detection of file configuration changes for Office 365 accounts is switched on if their security tooling allows for it, because although users can accidentally change their versioning settings, it is not very common behaviour to do so, so sudden changes would probably indicate something is up.
Other mitigations, such as prioritising so-called Very Attacked People, shoring up access management, updating disaster recovery and backup practice, implementing cloud security and threat intelligence, and implementing data loss prevention technology, will also be effective.
Defenders may also wish to add the following actions to their response and investigation, in case risky configuration change detectors are triggered:
- Increase restorable versions for affected libraries.
- Identify any previous account compromises or risky configuration changes for the affected account.
- Hunt down any suspicious third-party app activity and revoke OAuth tokens if found.
- Find out if the user had ever before behaved out of policy – such as taking risky OAuth app actions, being negligent with sensitive data, and so on.
The team disclosed the issues to Microsoft via its responsible disclosure path, but said Microsoft’s response was that configuration functionality for versioning settings within lists is “working as intended”.
Microsoft added that older versions of files can be “potentially” recovered and restored for an additional 14 days through Microsoft Support.
The team said: “Proofpoint attempted to retrieve and restore old versions through this process (ie, with Microsoft Support) and was not successful. Secondly, even if the versioning settings configuration workflow is as intended, Proofpoint has shown that it can be abused by attackers towards cloud ransomware aims.”
