The Prospect of Wiper Malware Attacks Against Microsoft 365 Tenants

Could Someone Get into Your Tenant and Wipe All Your SharePoint Online Files?

Daniel Chronlund’s February 14 blog about the threat of Microsoft 365 Wiper malware got me thinking about what steps tenant administrators should take to prevent hackers using permissioned Azure AD apps to remove data. Daniel specifically pointed to the Files.ReadWrite.All and Sites.ReadWrite.All permissions. These permissions allow apps to use Graph API requests to read and write (and delete) files stored in SharePoint Online sites and details of the sites. Daniel’s blog describes how he built an app to remove files from SharePoint Online sites, an act that a hacker might consider if they can gain access to a registered app with the necessary permissions.

A registered app could be planted by an attacker, a technique used to take over a tenant and use it to send spam, or it could be the result of a administrator granting consent to an app, perhaps after they clicked a link in a phishing email that resulted in their account being compromised. The app could be created in the tenant, or it could be an enterprise app configured to run in any tenant. What’s important is that the app receives sufficient Graph permissions to wreak havoc.

Restoring Deleted Files

Losing tens of thousands of documents because of an attack is a bad situation to be in. It might be possible to recover files using SharePoint’s Restore this library feature, unless the attacker chooses to empty the first and second-stage recycle bins. If the tenant has retention policies in place, they should still be able to recover deleted documents from site preservation hold libraries, but the process is manual and very time-consuming. Things might be even messier if the attacker decides to encrypt files instead of deleting them.

Recovery from a backup is usually better than manually searching the preservation hold library for files. Microsoft support can recover complete site collections, and ISVs offer more granular and more controlled recovery options. We don’t yet know how the Microsoft Syntex backup service will work in situations like this, but it seems like it’s the kind of circumstance that service should deal with well.

Tools for Wiping

You might assume that attackers are unlikely to resort to wiping large amounts of documents from Microsoft 365 tenants. They have other techniques to extract ransoms from compromised tenants. That’s true, but it doesn’t rule out someone running an attack for the sheer pleasure of causing massive disruption to an organization. Nor does it stop an internal attacker wanting to leave their mark as they depart a company.

Tools are available to wipe files. The code for Daniel’s wiper tool is in his GitHub repository. It’s a PowerShell script that calls Graph API requests to list files in libraries and deletes them. You could also take the script I wrote to report files in SharePoint document libraries and add the same kind of request that Daniel uses:

$Parameters = @{
                AccessToken = $AccessToken
                GraphMethod = 'DELETE'
                GraphUri = "https://graph.microsoft.com/v1.0/drives/$($DocumentLibrary.id)/items/$($File.id)"
            }
    
            if (!($WhatIf)) {
                $RootContent = Invoke-DCMsGraphQuery @Parameters
            }

I like the suggestion of using tools like those available to demonstrate to management just what can happen if attackers penetrate a tenant. There’s nothing like a demonstration of how easy it is to delete all the CEO’s files to accelerate investment in improved security, like justifying the expense of Azure AD Premium licenses or upgrading from Office 365 E3 to E5.

Review App Permissions to Prevent Microsoft 365 Wiper Malware

The prospect that someone might want to wipe data from SharePoint Online underlines the importance of reviewing and assessing the use of high-priority app permissions that hackers or other malicious parties might want to exploit. You don’t need to worry too much about delegate permissions. The danger comes from the misuse of application permissions, which allow an app access to data across the tenant.

I covered the need to review app permissions in September 2022 and shared a script that executes as a scheduled Azure Automation runbook to examine the permissions assigned to Azure AD apps, find the apps with high-priority permissions like Files.ReadWrite.All, and report them in a message posted to a Teams channel. The scheduled frequency is up to the tenant, but a weekly check should be sufficient. After all, this is just one of the tasks that administrators must take care of on an ongoing basis.

Including Sign-In Information

The current script doesn’t include any sign-in information for the service principals and managed identities that apps use to authenticate. Knowing if an app signs into Azure AD is valuable information because an inactive app is no danger. On the other hand, if many unexplained sign-ins for an app are in the log, it could be that someone is using the app for a malicious purpose.

To include the sign-in data, I used the Get-MgAuditLogSignIn cmdlet to retrieve the records for managed identities and app service principals and then checked each app against the sign-in records. If the script finds a match, it writes the date of the last sign-in to the PowerShell list holding the set of apps for review:

[array]$MIAuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'managedIdentity'))" -Top 2000 -Sort "createdDateTime DESC"

[array]$AuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 2000 -Sort "createdDateTime DESC"

$AuditRecords = $AuditRecords + $MIAuditRecords

ForEach ($AppRecord in $AppOutput) {
  $SignInFound = $AuditRecords | Where-Object {$_.ServicePrincipalId -eq $AppRecord.ServicePrincipalId} | Select-Object -First 1
  If ($SignInFound) { Write-Host ("App {0} last signed in at {1}" -f $AppRecord.DisplayName, $SignInFound.CreatedDateTIme) 
  $AppRecord  | Add-Member -NotePropertyName LastSignIn -NotePropertyValue $SignInFound.CreatedDateTime
   }
}

The final step in the script is to post the information for administrators to review to a suitable Teams channel (Figure 1). The data is sorted so that the apps with recent sign-ins are listed first.

The latest version of the script (available from GitHub) includes this code. The code is written for Azure Automation, but is easy to change to run in an interactive PowerShell session. And, of course, because it’s PowerShell, feel free to introduce your own enhancements.

Microsoft 365 Wiper Malware Attacks are More of a Potential Than a Real Threat

I’m not sure if attackers will want to wipe SharePoint Online data. But anything’s possible given the current level of threat that exists for systems connected to the internet. Although the most important thing is to keep attackers at bay by deploying tools like multi-factor authentication and conditional access policies, keeping a close eye on the permissions assigned to Azure AD apps, especially permissions that attackers can use to exfiltrate or remove data, means that you know what apps are dangerous and when they’re used.