Data Exfiltration in M365: Rclone Meets SharePoint

TL;DR

Why Should I Care? A Business Email Compromise can lead to data exfiltration from SharePoint.

What Should I Consider? Restrict user consent for applications in Microsoft 365 (M365).

Introduction

Rclone is a familiar tool, especially when talking about ransomware incidents. Threat Actors will often use rclone to exfiltrate data from a compromised environment. Many organisations have shifted away from traditional file shares towards cloud solutions such as SharePoint. There are many benefits with this shift such as allowing employees to access documents remotely without the need to be directly connected to the network. However, what happens when a Business Email Compromise (BEC) extends to data exfiltration out of a SharePoint?

Data exfiltration can occur without a Threat Actor compromising the network; only a cloud account is needed. This means a Threat Actor could potentially obtain the contents of an entire SharePoint site’s documents to which the compromised user has access.

What is Rclone?

Rclone is a command-line tool to manage and sync files to and from various cloud storage services. While it is a legitimate and highly useful tool, like many others, it can be misused. Threat Actors can exploit Rclone’s features for data exfiltration purposes. Rclone is even listed in the MITRE ATT&CK software catalogue, which details commonly used software by Threat Actors.

MITRE ATT&CK Rclone, Software S1040: https://attack.mitre.org/software/S1040/

Testing this out

What better way to understand this than by testing it out? To start, I created a test M365 tenant with a SharePoint site containing fake data.

The Objectives:

• Replicate the actions a Threat Actor would need to perform to exfiltrate data from SharePoint using rclone.
• Review the logs to determine what information is available for analysis.

The process is relatively straightforward and begins with registering a new remote. Rclone’s documentation on Microsoft OneDrive, which you can find at https://rclone.org/onedrive/ includes setup instructions. Notably, Microsoft OneDrive and SharePoint are configured within the same remote setup.

Where the Threat Actor is already authenticated within a browser, reauthentication is not required. This makes it easier for the Threat Actor especially where session token theft is required to bypass multi-factor authentication. The Threat Actor would be prompted to consent to add rclone as an application (by default, any user can consent to applications in M365).

Once authenticated the Threat Actor would then be prompted to specify the remote location including OneDrive, the root SharePoint site or a specified SharePoint site URL as shown below.

Once the remote is configured the Threat Actor would have the ability to access the contents of the SharePoint site using Rclone. As shown below is a list of the directories within the site.

With the following command, the Threat Actor would be able to exfiltrate a complete copy of all the SharePoint site’s data onto the Threat Actor’s machine.

.\rclone.exe copy SharePointRemote: C:\temp\SharePointSiteData

This is a concern!

This is pretty concerning, especially considering the sensitive information that might reside in an organisation’s SharePoint. This could include HR records, internal documentation and, unfortunately even plaintext passwords. If a Threat Actor successfully exfiltrates data on this scale, it could expose the organisation to significant privacy obligations and potential legal repercussions. Additionally, ransom groups might post the organisation’s data on leak sites or put it up for sale as part of their extortion tactics.

Forensic Artifacts

Let’s explore what is generated from a forensic point of view.

Unified Audit Logs

As a first step after containment, we can collect the Unified Audit Logs for the impacted user. Onced parsed and we begin to piece together what occurred. The visualization below clearly reveals a significant number of file download events.

Drilling down to a file download event we can see a couple of fields of interest including:

• ClientAppName: Rclone
• Operation: FileDownloaded
• ClientIP: IP Address
• UserAgent: rclone
• FileSizeBytes: 199.0
• SiteURL: Site URL
• ApplicationDisplayName: Rclone
• ObjectID: object URL

These fields are of value during an investigation as they assist in providing insight into questions such as:

• What data was taken? This can be achieved by compiling a list of all the ObjectIDs or SourceFileNames where the ClientAppName is rclone.
• How much data was taken? This can be achieved by totalling the FileSizeBytes where the ClientAppName is rclone.
• What was the IP address where the data was exfiltration initiated from? This can be achieved by reviewing the ClientIP field where the ClientAppName is rclone.

Microsoft Entra ID Portal

Whilst these details are included in the Unified Audit Logs we can review the rclone enterprise application logs within the Microsoft Entra ID portal. This can be achieved by:

1. Navigate to: entra.microsoft.com
2. Applications -> Enterprise applications
3. Select the application in this case rclone
4. Under activity, there are two log options of interest: sign-in logs and audit logs. The sign-in logs include any authentications to the application. The audit logs will include any adjustments to the application such as the original consent to the application, role assignments and permission grants as captured below with the registration of rclone in the testing.

Prevent this from happening!

Here are a couple of measures you can implement to prevent this from happening in your environment.

• Restrict User Consent for Applications
  • I believe this is one of the controls that you should disabled by default.
  • Change user consent for applications to “Do not allow user consent”. This will require an administrator to consent to an app being added.
  • Microsoft Documentation: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal
• Conditional Access Policies
  • Configure conditional access policies such as restricting risky sign-ins, non-managed devices and authentications originating outside of the operating countries.
  • Microsoft Documentation: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies
• Enforce Multi-factor Authentication (MFA)
  • MFA is a must, this goes without saying. MFA should be applied and enforced on all accounts.
• Monitoring for Suspicious Activity
  • Establish detections within a SIEM or similar solution such as Microsoft Defender for suspicious activity within your tenant. This should also be monitored.