Proofpoint’s Implausible Attack Against SharePoint Online

Multi-Factor Authentication Remains Best Block Against Attack

On June 16, Proofpoint published an article reporting how attackers could potentially conduct a ransomware attack against SharePoint Online and OneDrive for Business (the SharePoint version attack). According to Proofpoint, they “discovered a potentially dangerous piece of functionality” that “allows ransomware to encrypt files stored on SharePoint and OneDrive in a way that makes them unrecoverable without dedicated backups or a decryption key from the attacker.

The word dangerous doesn’t appear elsewhere in the article, so I’m not sure what the potentially dangerous piece of functionality is, apart from an implied criticism of the way SharePoint Online works.

In any case, since the article’s publication, I’ve received many questions asking if such an attack is possible. My response is that the attack described by Proofpoint is viable, but only when many different conditions come together to allow an attack to succeed.

Compromising Accounts

Attackers must gain access to a tenant before they can do damage. Using compromised or hijacked identities is a common route. Usually, attackers penetrate Azure AD accounts using attacks like brute-force password sprays or business compromise email. The simple fact is that organizations can blunt or negate these attacks by up to 99.9% (Microsoft’s figure) if they protect user accounts with multi-factor authentication.

After achieving access to an account, the ransomware attack first adjusts the versioning setting of target document libraries (or OneDrive for Business account) and then proceeds to “Encrypt the file(s) more times than the versioning limit.” The compromised accounts must be SharePoint site administrators or hold tenant administrative roles before an attacker can adjust the versioning setting for a site document library (Figure 1). An attacker can adjust versioning for the compromised user’s OneDrive for Business account, but that again depends on being able to get past multi-factor authentication.

Further mitigation is possible by ensuring that administrators use separate accounts for day-to-day work and making sure that the permissioned accounts do not receive external email . Alternatively, use Azure AD Privileged Identity Management and require accounts to seek approval for permissioned activities.

It’s possible that attackers could convince administrators to grant consent to an app to access SharePoint Online and OneDrive for Business. With the appropriate permissions, the app can update SharePoint Online sites and OneDrive for Business accounts. This is something to guard against by periodically checking the apps present in a tenant and the permissions assigned to each app. If you use Microsoft Defender for Cloud Apps, the App Governance add-in might be useful.

Another compromise method described in the article is to hijack a logged-in user’s account or by capturing a valid access token. This is true, but the user needs to be a site administrator to adjust versioning for a SharePoint Online document library. The attacker could, however, encrypt the user’s own files.

Attacking SharePoint Online Versioning

Versions are an important part of SharePoint’s ability to restore files back to a specific point (the Restore this library feature). If the AutoSave feature is enabled for Office documents, Word, Excel, and PowerPoint save versions automatically as users edit documents, meaning that over time a collection of versions accumulate (Figure 2). Application that don’t support AutoSave create new versions when users save files. Users can view, restore, or delete individual versions.

The attack technique is to create sufficient new versions of files to exceed the versioning limit set for the document library. Each round of encryption creates a new version of the target file, and eventually only encrypted versions of files exist in the document library because SharePoint Online clears out the non-encrypted versions after the number of changes exceed the versioning limit. For SharePoint Online document libraries (including OneDrive for Business, the versioning limit ranges between 100 and 50,000.

Proofpoint says that the attack is easier if you reduce the version limit to one. I haven’t tried this, but it is possible to use the Pnp-SetList PowerShell cmdlet to control version settings, so I guess this is how it’s done. Proofpoint acknowledges that “Encrypting files 500+ times is unlikely to be seen in the wild. It requires more scripting and more machine resources while making your operation easier to detect than the next method.” I guess that increasing the number of versions kept for documents should help to resist attacks like the one described.

Proofpoint also acknowledges that copies of files copied to workstations by the OneDrive sync client can reduce the impact of the attack. This is true, but only if the copies of the files remain offline.

Use Our Software!

Much of the latter part of the article describes various Proofpoint products to help resist attack. In other words, all will be well if you use Proofpoint’s CASB, targeted attack protection, backup and recovery, cloud security, and data loss prevention. I’m not so sure.

The first and most important consideration is to stop attackers getting in. That’s where multi-factor authentication comes in. After that, basic good tenant management practices will stop the attack described by Proofpoint happening. And if you want to use other ways to protect a tenant, consider exactly what gap you’re trying to fill and if a standard feature built into Office 365 can solve the problem. If not, look at third-party and Microsoft solutions.

As to backup, Proofpoint said that they unsuccessfully tried to have Microsoft support restore older versions of SharePoint files. Microsoft backs up SharePoint sites every 12 hours and retains the backups for 14 days, meaning that support can restore a complete document library (overwriting everything that’s there) if necessary. Apparently, this process didn’t go so well when Proofpoint tried it out. However, without further details, it’s impossible to know what the problems were.

In a nutshell, I’m unconvinced that “Proofpoint has shown that it can be abused by attackers towards cloud ransomware aims.” Whatever that sentence means!