Rclone is a data syncing tool often used by threat actors to exfiltrate data during a ransomware attack. Typically, the actors deploy Rclone after gaining remote access to the victim’s network. However, recently, Kroll experts have noted the use of Rclone in M365, using credentials stolen through network compromises or phishing attacks with minimal privileges to stealthily exfiltrate large amounts of SharePoint/OneDrive data.
Kroll experts were able to replicate an event where threat actors used Rclone to download a massive number of files in a little over one hour from SharePoint/OneDrive via a Microsoft 365 (M365) account—all without remote access to a host. Kroll discovered that in order to sync data from a server or exfiltrate SharePoint/OneDrive data, the threat actor simply needs to compromise an M365 account with sufficient privileges.
More troubling, the compromised M365 account does not necessarily need to be a global administrator account, especially in the case of overly permissive configurations; Rclone may be used with any user account.
Figure 1: Settings Configured to Allow Non-Admin User Consent for Apps
Rather, the account only needs permissions to create and consent to enterprise applications. The account also needs access to the SharePoint site the threat actor is targeting with Rclone.
Digital Forensic Analysis
Kroll’s testing determined that when attempting to create an enterprise application for Rclone in Azure Active Directory (AAD), the threat actor needs access to an M365 account with the ability to consent to applications.
Figure 2: Rclone seen in Azure Enterprise Applications
In properly configured tenants, this means a threat actor must have a global administrator account.
Figure 3: Properly configured settings for user consent to apps
In the non-interactive sign-in logs in AAD, our experts were able to see the Rclone application and user agent connecting to the Microsoft Graph API. Kroll observed that all users utilizing the Rclone application will appear in this log, which goes back seven days or one month, depending on AAD license level.
Figure 4: Application and User Agent Where Rclone Was Present
Figure 5: Azure Non-Interactive Sign-ins via the Azure Portal
Figure 6: Azure Enterprise Application Sign-Ins
Once Rclone has been installed, our experts analyzed the available M365 logs and were able to see FileDownloaded events in the unified audit log when SharePoint\OneDrive files were downloaded via Rclone within M365. For context, unified audit logs track user and account actions across all the M365 services where logging is enabled; Microsoft maintains these logs for a period of 90 days for most license levels on a first-in-first-out basis.
[{"CreationTime":"2022-08-22T18:54:46", Operation":"FileDownloaded","Workload":"OneDrive","ClientIP":"XX.XX.XX.XX","ObjectId":"https:\/\ my.sharepoint.com\/personal\/Documents\/A test document.docx","UserId":[email protected], EventSource":"SharePoint","ItemType":"File"," UserAgent":"rclone\/v1.59.1", FileSizeBytes":11844, SourceFileExtension":"docx","SiteUrl":"https:\/\/my.sharepoint.com\/personal\/","SourceFileName":"A test document.docx","SourceRelativeUrl":"Documents"}]
Figure 7: Unified Audit Log File Downloaded Entry
The user agent string with these FileDownloaded events identified the request as Rclone. However, Rclone can be configured to show a different user agent string. User agent strings are a means to identify the connection method and operating system connecting to a web server for content and behavior customization. Since the log entries show the SharePoint path and document name, forensic examiners can find exactly what data was exfiltrated with Rclone if unified audit logging is enabled for the tenant and Rclone activity can be distinguished from other activity, such as by the user agent string.
Kroll experts tested this numerous times, and from our testing, we concluded that the logging is accurate for the files that were exfiltrated using Rclone via M365.
In Kroll’s experience, actors have typically used phishing attacks to conduct financial fraud, such as misdirecting payments to the threat actors’ account, rather than for collection of sensitive data for the purposes of M365 data theft/extortion. However, this new tactic gives actors a stealthy way to exfiltrate large amounts of data without alerting organizations to the attack. By sharing our findings, we hope organizations will maintain vigilance over suspicious activity in their M365 tenants, and in particular, institute more stringent permissions for application registration and consent.
Recommendations
- Review Azure Enterprise Applications regularly and remove third-party applications that are not needed for business purposes.
- Do not allow non-privileged accounts to consent for applications (An admin will be required for all application consent.)
- Only grant the Global Administrator role to dedicated administrative accounts.
- Administrators should use non-privileged accounts for email and other everyday purposes and have separate named accounts with administrator roles.
- Enable and enforce multifactor authentication (MFA) for all M365 users.
- Conduct phishing training and testing for all M365 users to raise awareness and potentially lessen the likelihood of a compromise.
- The Consent to Application UAL event should be uncommon. If your organization uses a SIEM to alert on sensitive events, include this event and confirm that all applications are authorized.
Figure 8: Consent to Application Event
Examiners can find evidence of Rclone being used in M365 in five primary places. Be sure to check them regularly:
- Azure Enterprise Applications
- Azure Non-Interactive Sign-Ins (Check Application ID and User Agent String)
- Azure Enterprise Application Sign-Ins (Enterprise Application > Activity > Sign-Ins)
- Unified Audit Log FileDownloaded Events (Check User Agent String)
- Unified Audit Log Consent to application Events (Check for possibly compromised accounts and unfamiliar applications)
Securing email platforms and delegating proper permissions to users based on their required access is crucial to protecting your organization. Regularly providing training and ensuring MFA is enabled can help prevent threat actors from gaining access to your network.
If you suspect suspicious activity when reviewing logs, Kroll experts are available to help 24x7 via our cyber hotlines or our contact us page.
Additional Business Email Compromise Resources
- Cyber Extortion Gets Personal – The Next Step in Email Compromises
Kroll experts have identified threat actors leveraging phishing attacks to gain access to key email and administrative-level accounts, exfiltrate hundreds of gigabytes (GBs) of data, and then initiate high-pressure extortion initiatives involving clients, colleagues, senior executives and even family members. - Business Email Compromise Trends and Mitigation
While published in 2019, this article offers still relevant insight into how business email compromise attacks are targeted at non-technical executives, shares real case studies, and provides practical tips to spot wire fraud and mitigate BEC incidents. - Case Study: Office 365 Business Email Compromise Investigation
A detailed study into how a BEC against a financial services company took place, its consequences (including massive exposure of financial information), and how Kroll was able to remediate the threat and increase the organization’s cyber resilience.
