One Drive, Double Agent: Clouded OneDrive Turns Sides

Over the past few years, ransomware has emerged as one of the most significant cybersecurity threats. Recent research conducted by Sophos indicates that the situation is becoming increasingly dire. Notably, the payments demanded by ransomware groups have surged, making the attacks even more costly for victims. Additionally, an alarming 66% of organizations have reported being targeted by ransomware attacks in the last two years alone. The severity of the ransomware threat has even prompted the White House to designate it as a national security concern. 

To better protect ourselves and combat this ever-evolving threat, we must be proactive in identifying new methods malicious actors could use to deliver ransomware. My most recent research process set out to do just that. Rather than the traditional ransomware method of gaining access to a target computer and executing malicious actions locally, like encrypting files, I wanted to see if I could gain initial access and then utilize legitimate programs to remotely execute malicious activities for me. 

Little did I know that I would stumble upon a somewhat unconventional approach utilizing Microsoft OneDrive that allowed me to develop a ransomware variant that could encrypt sensitive data and prevent/disable file recovery features, while it wasn’t executing code on the victim endpoint. My ransomware variant was able to execute these malicious tasks using legitimate programs and flows to avoid raising suspicion. It was also entirely undetectable by standard security measures and could not be traced back to me. 

I first presented this research at Black Hat USA 2023 and am sharing it with the broader security community in this post. Below, I will explain how, after gaining initial access to a victim’s computer, I manipulated the OneDrive app to sync specific files using junctions and gained access to the victim’s OneDrive account via a stolen access token. Next, I’ll show how I used the victim’s OneDrive account to encrypt files on the target machine remotely and prevent any recovery attempts. Finally, I will highlight the vendor response and explain how SafeBreach is sharing this information with the broader security community to help organizations protect themselves. 

The Research Process

Searching for a Double Agent: Discovering OneDrive as an Unexpected Ally

As I began my research, I knew I needed a “double agent” program—something that could perform malicious actions on my behalf while maintaining its legitimate facade. After careful consideration, I decided a promising candidate for this role would be a local agent for Windows that was responsible for synchronizing files with a cloud storage service. These agents typically create local folders and duplicate files from the cloud, inherently engaging in mass file operation on the local computer.

I decided to focus on OneDrive, Microsoft’s cloud storage service, as it is a widely used service that has been installed by default on all Windows versions since 2013. From an impact perspective, this meant that any Windows computer an attacker could get access to might be vulnerable to the ransomware variant I was looking to create, making it an ideal candidate for testing. 

As I delved into Microsoft’s security settings and features for OneDrive, I discovered that Microsoft uses OneDrive for ransomware data recovery and actively promoted it as a means of safeguarding important files from ransomware attacks. Moreover, Microsoft had integrated built-in ransomware detection and recovery measures into OneDrive, adding to its appeal for my research. 

As far as I knew, OneDrive was meant only to synchronize files inside the local OneDrive sync directory. But to accomplish my research goal, I needed to find a way to use OneDrive to modify and sync files outside of this directory as well, while retaining the legitimacy of these actions. I wasn’t sure if this was even an option in OneDrive. After a little investigating, I found that Microsoft recommends creating symbolic links to synchronize other directories on your computer. 

Using this method in my activities would be important, as it would ensure OneDrive viewed the synching of files outside the OneDrive sync directory as legitimate. Symbolic links, however, can only be created by admin users by default. To achieve my objective, I decided to use junctions within the local OneDrive sync directory instead, since junctions do not require any special permissions and work exactly the same for this matter as symbolic links. 

With the junctions in place, I found myself in a scenario where OneDrive servers could modify, create, or delete local files on a computer using the native OneDrive agent. 

Remarkably, this setup bore a striking resemblance to the way malware communicates with its command-and-control (C2) server. This realization reinforced my belief that I had identified a suitable double agent in OneDrive.

Recruiting a Double-Agent Asset: The Significance of Tokens 

Next, I needed to gain access to the OneDrive account linked to the target user on the victim’s machine. If successful, I could manipulate files on the victim’s OneDrive cloud storage, which would prompt the local native OneDrive client to synchronize these changes from the cloud. This would effectively allow me to modify files on the victim’s system without having to execute code and without arousing suspicion.

One option to gain control of the OneDrive account that is linked to the target user after initial access to their computer is to log out and log into a different OneDrive account. However, this approach can be noisy and draw attention. Instead, I decided to explore stealing the credentials or access token of the already logged-in account. 

While getting the credentials might be difficult without some sort of phishing activity, I decided to investigate the OneDrive Logs (ODLs) associated with the target account to see if I could find any information there that might help me steal the access token. The logs are stored in the current user directory, so they can be read by the current user. Although the logs aren’t saved as raw text, they could be easily parsed using a simple python script I found. I was shocked to find that the logs actually contained the access token for the OneDrive account. 

That meant that any process or program running on the computer with only the current user’s permissions could read the ODLs and steal the access token for the associated OneDrive account. 

Next, I needed to understand which type of token it was. OneDrive supports two types of tokens: 

After sniffing the traffic from the native Windows app, and knowing that the native Windows app is the one to write into the ODLs, I saw that the WLID token I found needed to be prefixed with the string “WLID1.1 t=”. Once I did that, I was able to successfully send multiple API requests to the victim’s OneDrive account. This allowed me to change settings and edit, create, and delete files on the victim’s OneDrive account.

Exfiltration and API Requests: Orchestrating Remote Encryption

Next, I wanted to be able to send these API requests from the attacker’s computer, rather than the victim’s computer. To accomplish this, I needed to exfiltrate the access token to the attacker’s computer. 

Fortunately for me, OneDrive is also an effective exfiltration tool. I simply had to upload a file containing the access token to the victim’s account—in doing so, I was only communicating with the victim’s account, rather than a C2 server, ensuring the communication was legitimate. I then shared that file with an email account belonging to the attacker—the email had to belong to a Microsoft account or an error was given (as seen below). 

Once an appropriate Microsoft email account was entered, the attacker received an email from a Microsoft server, giving them access to the file and the victim’s OneDrive account. I was then able to modify files within the cloud storage of the OneDrive account, prompting OneDrive to synchronize the changes locally. 

File Recovery Prevention

As I began to consider how a victim might recover files after such an attack, I realized that I also needed to find a way to disable OneDrive’s file recovery features since part of this attack flow includes target files being uploaded to OneDrive. I realized that OneDrive’s Recycle Bin and File Versioning features were critical aspects to address. 

OneDrive’s file versioning keeps 500 previous versions of each file, even if those files are deleted and restored later from the OneDrive Recycle Bin. In order to prevent a victim from being able to access previous versions of their files, an attacker would need to encrypt the files, delete them from the victim’s OneDrive account, empty the Recycle Bin to remove all previous versions, and then add the encrypted files back to their original locations. An attacker could also potentially skip the first step of encrypting the files, and instead just delete them, empty the Recycle Bin, and restore them to their original locations as encrypted files without the version history. 

While this can make the attack faster, starting with encrypting the original versions of the files promises that they cannot be restored later from the disk with file recovery programs. An attacker can also choose the faster flow without the first step of encryption but, to be certain that files cannot be restored later from master file table (MFT) entries marked as free using file recovery programs, the attacker can later create a huge file on the disk that completely fills the disk with random content in it.

At first, I wasn’t optimistic about emptying the Recycle Bin directly, considering it was a recovery feature. I expected OneDrive to require additional validation to prevent such actions, and I was right. When I tried to access OneDrive’s Recycle Bin from the Windows OneDrive app, a browser opened and loaded the Recycle Bin’s web page. After trying to empty the Recycle Bin and sniffing the HTTP request that was being sent, I saw that the request was actually different from all the other API requests that were sent to ‘api.onedrive.com‘. Instead, this one was sent to ‘skyapi.onedrive.live.com‘, didn’t have an ‘Authorization’ header, and added two other headers called ‘AppId’ and ‘canary’. 

The value of ‘AppId’ stayed constant between emptying requests, even if done from different accounts, but the value of the ‘canary’ header kept changing. Unfortunately, after tracing back its origin, I saw that the value of the ‘canary’ header was given inside the JavaScript of the HTML page of the Recycle Bin itself, but only if a cookie called ‘WLSSC’ was provided when accessing the page. It seemed like I’d hit a wall, because I did not have a way to get the ‘WLSSC’ cookie except for reading it from the browser’s cookie files, which is highly detectable and malicious. I would have to continue to fine-tune the attack strategy to ensure the attack remained undetectable and legitimate.

OneDrive Android API

Upon further exploration, I made some exciting discoveries about OneDrive on mobile, particularly the native Android OneDrive app. I knew native apps don’t tend to use cookies and, as opposed to the Windows OneDrive app, accessing certain features through a WebView or browser on mobile for the Android OneDrive app could result in a poor user experience. As expected, on Android, I found that I could empty the OneDrive Recycle Bin from the app itself without needing a browser, which increased my suspicions.

After analyzing the traffic from the app, I observed that almost the same HTTP request used to empty OneDrive’s Recycle Bin on the web version of OneDrive was also being sent from the Android app. However, this time, it was sent to a different domain (skyapi.live.net) and was done using the WLID token—the same token that I was able to steal from the ODLs. This seemed odd because if an attacker had access to the token for encrypting or deleting files, it didn’t make sense that the same token would allow them to empty the Recycle Bin and prevent recovery efforts.

During my investigation, I discovered more shortcuts in the Android app. As opposed to the Windows and web versions of OneDrive, I could share a file with a temporary email address not linked to a Microsoft account in the Android app. Surprisingly, this could be done without any validation, making the exfiltration process even more streamlined for attackers, as they wouldn’t need to create a Microsoft account.

To summarize, the attack workflow involved: 

1. Gaining initial access.
2. Manipulating the OneDrive app to sync specific files by using junctions inside the OneDrive sync folder.
3. Stealing the OneDrive access token from the victim’s ODLs. 
4. Uploading a file with the access token to the victim’s OneDrive cloud storage account.
5. Sharing the file with an email address belonging to the attacker to give them access to the victim’s OneDrive cloud storage account.
6. Using the victim’s OneDrive account from the attacker’s computer to encrypt files on the target machine remotely.
7. Delete all the files from the victim’s OneDrive account.
8. Empty the OneDrive Recycle Bin.
9. Restore all the files with their encrypted contents back to their original location, so the victim can still see that the files are present but they are encrypted.

This process effectively created a ransomware attack that operated legitimately by one of the most trusted programs on the computer and without being present on the victim’s machine, while disabling any options OneDrive offers for recovery.

Shadow Copy Recovery: Inflicting Irreversible Damage

Although I had developed an effective attack workflow, I still wanted to explore the possibility of preventing recovery on the local Windows environment. Shadow Copy is a technology included in Microsoft Windows that can create backup copies or snapshots of computer files or volumes on the hard drive—these copies are usually targeted by ransomware for deletion. So, I set out to investigate if I could delete shadow copies using this ransomware attack flow.

However, it became clear that OneDrive itself does not have a built-in feature for deleting shadow copies. This meant I couldn’t use OneDrive as a true double agent for this purpose. Instead, I needed to find a way to execute commands using OneDrive. 

I discovered that its installation directory is located in the current user’s directories and is writable by the OneDrive agent running with the permissions of the current user.

Here’s where I got creative. I modified the workflow to add another junction at the beginning with the other junctions that pointed to the installation directory. By doing so, I created a scenario where OneDrive itself would write executables into its own installation directory, making it appear like a regular update.

However, I faced one hurdle: while OneDrive was running, it used the executables in the installation folder. While executables are executed, they are opened in a read-only file sharing mode, which prevents them from being overwritten. To circumvent this, I needed to find an executable in this directory that wasn’t running while OneDrive.exe was running but could still be easily triggered.

After some investigation, I identified Microsoft.SharePoint.exe as a suitable executable in this directory. It was run by OneDrive each time the program started, but it terminated after a few seconds if the current user’s Microsoft account was not linked to any SharePoint libraries.

This presented an opportunity. I replaced the Microsoft.SharePoint.exe executable with my own malicious executable that listened for commands from a file I placed inside the victim’s OneDrive storage. Then, the next time OneDrive started, it would run my executable. By using this command-execution technique, I could potentially delete shadow copies on the target machine using the ‘vssadmin delete shadows /all’ command.

However, I need to mention a disclaimer: this method is applicable only if the target user is an administrator, as only administrators can delete shadow copies. Additionally, I implemented a User Account Control (UAC) bypass inside the executable to achieve this.

Surprisingly, when testing my attack against the Cybereason endpoint detection and response (EDR) environment, I found the most preventive settings on the default environment that Cybereason provided did not prevent shadow copy deletion. This allowed me to execute the technique successfully. Cybereason pointed out that preventing shadow copy deletion is possible on their product, but it must be enabled by contacting their customer success team. 

Curious to see how other EDR solutions would respond, I tried it with SentinelOne. I first wanted to see exactly what happens during the shadow copy deletion process, so I created a few shadow copies myself and tried to delete them. Oddly, the process I used was killed and a detection was raised, but the shadow copies I created were actually deleted. However, there were two shadow copies that were created by the SentinelOne XDR itself that were left after the deletion. As a result, I understood that in order to really prevent recovery, I probably had to delete them as well. After some trial and error, I realized that if I created four shadow copies, deleted them all, and repeated this process four times, SentinelOne’s shadow copies were deleted too.

With that being said, the real highlight appeared when I combined this bypass with the command execution technique using the executable that I replaced with SharePoint’s executable. When I did this, no detection was raised at all. Apparently, while SentinelOne XDR is installed, any user can replace SharePoint’s executable with a malicious one and execute multiple malicious actions without being detected or prevented.

Disabling Security

As a final step, I explored potential loopholes or overlooked areas. While exploring OneDrive’s settings, I came across an email notification feature that alerts users when many files are deleted. 

My initial thought was that an attacker gaining access to delete files on OneDrive using a stolen token wouldn’t be able to disable such a security feature. However, to my surprise, I could turn off the notification using a simple HTTP PATCH request with the token that I found in the logs.

Upon further examination of the JSON structure sent in this API request, I found another setting that seemed much more important for my needs. Its name was “RansomwareDetection” and was set to true.

It was not exposed in any interface that OneDrive offered: not on desktop, not from the browser, and not from the mobile apps. It looked like a mistake. This caught my attention, since Microsoft claimed to have a built-in ransomware detection feature in OneDrive. While I had already managed to run this ransomware attack flow multiple times against multiple accounts and hundreds of files without any detection being raised, I still wanted to see if I could disable this setting.

First, I attempted to change this ransomware detection setting to false using the same token I stole. Surprisingly, I could modify the setting without any validation or issues. It struck me as odd that I could essentially turn off the very feature meant to protect the victim from ransomware attacks just through a simple API call.

Later, Microsoft clarified that this setting was meant to enable or disable an email notification related to ransomware detection, but it still left me puzzled. Despite the explanation, I had not received any notifications related to ransomware detection during my attack runs. This discovery was concerning, as it didn’t make sense that an attacker gaining access to encrypt files on OneDrive using a stolen token would also be able to turn off a notification about it that was meant to notify the victim of an attack. It’s basically like allowing any unprivileged process on a computer to disable notifications from an EDR or an AV.

EDR Evaluation

EDR evaluation against my original attack flow revealed that none of the tested products, including Microsoft Defender for Endpoint, CrowdStrike Falcon, Palo Alto Cortex XDR, SentinelOne XDR, and Cybereason, were capable of detecting or preventing the ransomware via this method. With the addition of the shadow copy deletion stage, this attack flow was still successful even when two of the EDRs we tested were installed (Cybereason and SentinelOne). 

Below, I provide additional details about the detection and prevention methods my ransomware workflow was able to bypass.

Decoy Files Detection

File decoys, where decoy files were placed in highly targeted/sensitive directories to observe process behavior, did not trigger any detection about ransomware when they were encrypted by OneDrive as part of this ransomware attack flow.

Ransomware File Extension Detection

Most ransomware families add a file extension to encrypted files so that victims will realize that an attack has occurred. For example, a file named “important_file.pdf” would be renamed to “important_file.pdf.encrypted.” EDRs monitor for these known file extensions, which is another indication that a ransomware encrypted files. The ransomware I created was able to rename files to have known ransomware file extensions (e.g., “.encrypted”, “.wnry”), and EDRs still did not detect or prevent anything as a result, even when the ransomware added these file extensions to decoy files after they were encrypted. The image below shows an example of encrypted EDR decoy files with an added ransomware file extension. 

Controlled Folder Access Ransomware Protection Feature

Microsoft’s Controlled Folder Access is an effective ransomware detection and prevention feature on Windows that prevents processes that it doesn’t trust from modifying or deleting any of the files that it protects. It has a “Protected Folders” list to determine the folders that it protects. By default, it has most user libraries in it, such as the Documents folder for example. The Controlled Folder Access feature does not prevent or detect the file modification or deletion actions that are done using OneDrive. The feature blindly trusts OneDrive, which basically allows any attacker to use OneDrive in order to bypass this feature.

Static Signature-Based Detection

Static signature-based detection is not even relevant for this attack. That is because there is no ransomware executable running on the victim endpoint. All that an attacker has to run on the endpoint is one very legitimate and simple executable or just a few command lines that create junctions, read logs, and send an API request to the victim’s OneDrive account.

Shadow Copy Deletion Prevention Bypass & Allowlisting an Executable (SentinelOne)

We were able to bypass the prevention of shadow copy deletion that the SentinelOne XDR implements. In addition, we were able to undetectably execute different malicious actions, like placing startup tasks in the startup folder or deleting shadow copies, by executing them from an executable in place of the original Microsoft.SharePoint.exe executable.

Machine Learning & Artificial Intelligence Approaches

None of the EDRs that we tested that implement machine learning or artificial intelligence approaches have managed to detect this ransomware.

Introducing DoubleDrive 

During my Black Hat presentation, I introduced DoubleDrive, a tool I developed to demonstrate the ransomware attack flow using OneDrive as a double agent.

The demo of DoubleDrive adeptly showcases the seamless execution of the ransomware attack flow, utilizing OneDrive as a double agent to encrypt files on the victim’s machine and prevent OneDrive’s recovery features. It also effectively highlights the attack’s evasive nature against Palo Alto Cortex XDR, a prominent EDR solution, thus raising significant concerns for cybersecurity professionals and organizations. For further examination and research, the source code for DoubleDrive is available on GitHub.

Vendor Response 

During my research, two of the cases that were reported to Microsoft about OneDrive were assessed with a security impact of escalation of privilege and an important security level. Although no CVE was issued, Microsoft acknowledged these reports in their Security Researcher Acknowledgements for Microsoft Online Services and fixed OneDrive so that it would not write an account’s WLID token in the ODLs. Microsoft did not provide specific comments about DoubleDrive bypassing their Microsoft Defender for Endpoint EDR.

I also reported all bypasses to all affected EDR vendors. CrowdStrike, Cybereason, and Palo Alto responded positively and addressed the flow. I did not receive a response from SentinelOne directly; however, I did reach out to SentinelOne’s HackerOne program as well and received a response that there did not “appear to be any security implications as a direct result of this behavior.” 

Key Takeaways 

As adversarial tactics become more sophisticated, this research has made it clear that we must: 

• Avoid placing unwavering trust in any process, even if it is an executable developed by a reputable company like Microsoft. Security vendors must not assume that built-in programs are inherently safe, as there could be instances where attackers manipulate their processes to carry out malicious actions. Instead, security measures should be implemented to identify and prevent such flows where attackers can influence legitimate processes.
• Be prepared for the next generation of ransomware attacks, moving beyond the traditional focus on a malicious executable that encrypts files. As demonstrated in this research, ransomware can be executed through other means, such as utilizing legitimate cloud services like OneDrive as a double agent. Understanding and anticipating these novel attack vectors is crucial in developing effective defense strategies.
• Invest in separating access between regular functionalities and security features. Allowing an attacker with access to do damage to disable critical security features such as ransomware and mass deletion detection notifications with the exact same access is counterintuitive and dangerous. Security measures should be designed to prevent attackers from tampering with security settings, ensuring the protection of data and systems.

Conclusion  

The attack flow through OneDrive proved to be highly evasive against various EDR solutions, effectively encrypting files and executing malicious actions without triggering any detections or prevention measures. This poses significant challenges for security teams in detecting and mitigating such attacks effectively. To help mitigate the potential impact of these vulnerabilities, we have: 

• Responsibly disclosed our research findings to the vendors of the EDR products we tested as noted above. Some vendors have released patches, while others have not.
• Shared our research openly with the broader security community here and at our recent Black Hat presentation to enable organizations to monitor their EDR configurations more vigilantly and stay informed about potential security updates to protect against such sophisticated attacks.
• Provided a research repository that includes tools that enable the verification of this type of attack and serve as a basis for further research and development. 
• Added original attack content to the SafeBreach platform that enables our customers to validate their EDR products against different vulnerabilities, attacks, and techniques, including the findings from this research to significantly mitigate their risk.

It is important to note that while we have done our best to test the EDR products we had access to, it is not feasible for us to test every product on the market. By making this information available to the security community, we hope to minimize the ability of malicious actors to exploit these security gaps and provide EDR vendors and users with the knowledge they need to take immediate action on their own.

We believe it is critical for all EDR vendors to proactively test their products against this type of attack and, if necessary, develop a remediation plan to ensure they are protected. We would also strongly encourage individual organizations that currently utilize EDR products to consult with their vendors about these kinds of attacks and immediately install any software updates or patches they provide.

For more in-depth information about this research, please: 

• Contact your customer success representative if you are a current SafeBreach customer
• Schedule a one-on-one discussion with a SafeBreach expert
• Contact Kesselring PR for media inquiries 

Credits

As for the WLID token extraction, there is an alternative method that uses a process dump of the OneDrive process on a Windows machine and searches for the string “WLID1.1 t=” parameter. This method was credited to Ariel Gamrian, Threat Security Researcher at SafeBreach.

About Our Researchers

Or Yair is a security researcher with over six years of experience in cybersecurity. Currently a researcher in SafeBreach Labs, he started his professional career in the Israel Defense Force (IDF). Most of his work focused on platform research, including Linux kernel components and some Android as well. For the last two years, Or has been drawn into the Windows world and currently focuses on innovative vulnerability research of the operating system’s components. Or has already impacted threat mitigation by widely sharing his discoveries internationally at conferences like Black Hat USA 2023, RSAC 2023, Security Fest 2023, CONFidence 2023, HackCon Online 2023, and Black Hat Europe 2022.