Ransomware in OneDrive

Attack technique

Technique name: Ransomware in OneDrive

MITRE ATT&CK

• Tactic: Impact
• Technique: Data Encrypted for Impact (T1486)

Technique description
Adversaries may encrypt data on target systems or on large numbers of systems in a network to interrupt the availability of system and network resources, usually for financial motives. They can attempt to render stored data inaccessible by encrypting files or data on local and remote drives and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware) or to render data permanently inaccessible in cases where the key is not saved or transmitted.

OneDrive is a cloud-based file storage and synchronization service offered by Microsoft as part of its Microsoft 365 suite (formerly known as Office 365). Ransomware attacks targeting OneDrive can have far-reaching consequences, as they can compromise critical data for individuals and organizations.

Insights from threat intelligence
As of the day of writing these words, no official records of ransomware in OneDrive environments are known to the public. However, the cyber security community has been researching the Microsoft 365 Cyber landscape and found significant findings, along with publicly available proofs-of-concept (POCs) that showcase that the ability exists. Ransomware activities in OneDrive can be seen made by different entities inside Microsoft products, such as user accounts, service accounts, and even third-party applications and integrations.

References:

• Safebreach - One Drive Double Agent
• Proofpoint- Cloud Security Proofpoint Discovers Potentially Dangerous Microsoft Office 365 Functionality
• Velosio - How One Drive for Business Protects Documents and Data from Ransomware

Threat hunting thesis breakdown

Data theft and encryption

Relevant data sources

• Office 365 Audit Logs

Thesis explanation

Ransomware in the cloud can bear many shapes of execution, but the main goal remains the encryption of files. Microsoft 365 doesn’t have built-in encryption capabilities for files in OneDrive volumes, therefore the encryption of the file system’s content is likely to happen by:

1. Downloading the content of the files from Onedrive itself. This can be made from a web interface such as Sharepoint, from a synced desktop with a OneDrive client agent, from a 3rd party application access, or other methods involving Microsoft Graph API.
2. Encrypting the content of the files.
3. Modifying each file with its encrypted content, or uploading a new file and deleting the original file.

Recovery tampering
When deploying ransomware, threat actors would make sure that the files are not recoverable. 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.
There is no direct way of deleting the version history of a file. However, there are still workarounds to bypass this limitation. In order for threat actors to disarm users from restoring their data, they need to perform a permanent delete. Here are two meth:

1. Move a file to the Recycle Bin, empty the first stage Recycle Bin, and empty the second stage Recycle Bin.
2. Direct Graph API calls for a permanent delete of a file.

Uploading the encrypted content
When a threat actor wishes to upload the encrypted content, he may choose one of two options:

1. Modify the original file, duplicate it to the same directory (the new file will not have a version history), and delete (as described in recovery tempering) the original file
2. Directly delete (as described in recovery tampering) the original file and upload the encrypted content as a new file.

Option 2 is quicker, but both are feasible.

Other signatures

• Ransom note - Usually, a threat actor will leave a plaintext note to the users with an unfortunate notice of a ransom, instructions on the ransom payment methods, and deadlines. This is the most clear evidence for detecting a ransom that took place. However, based on Office 365 logs, the content of target files is not visible in Microsoft logs telemetries, and the file name may not be indicative for detection.
• File extension - In some cases, the attacker may change the extension of the files. The purpose of this behavior can be to set a clear and intimidating appearance of the impact. However, this behavior is not mandatory for the encryption process.
• Scrambled\encrypted file names - In case of downloading a file and deleting it right after, a new file is expected to be uploaded. However, since there is no guarantee of having similar names. newly encrypted files can have randomized stings as names, which the attacker can resolve to the original name in case of decryption. Therefore we prefer not the rely much on the newly uploaded file name for correlation.

All of these signatures can help in a ‘visual’ assessment of cases where ransomware is suspected of taking place, but will probably not be complete enough to generate automated ‘leads’.

Immediate VS staged execution
In this threat-hunting journey, we shall look for two types of ransomware execution forms that are known in the wild:

1. Immediate execution - The attacker executes an automated playbook that iterates over all the accessible files and immediately completes the encryption process
   This form of execution is more efficient for the attacker, as it doesn’t require him to have storage resources and they have an immediate effect on the victim.
2. Staged execution - The attacker executes the ransomware in two independent stages, where he first clones all the files ‘locally’ and then uploads the encrypted content later, either on-demand or with a built-in delay mechanism.
   This form of execution may allow the attacker to assess the value of content he can compromise and set his ransom preferences and expectations accordingly.

In both execution forms, we expect to find the following order of activities:

1. Data Retrieval
2. Remote Modification

The main difference between the forms is the time interval between these steps.

Detecting an immediate data theft and remote encryption
Detection of single file encryption is not effective when isolated from similar files’ activities at the same time period. In order to better the possibility of catching an automated ransomware attack, we will define two different time scopes:

• Single file encryption - The estimated time that takes to complete an encryption of a single file - 5 seconds
• Multiple files encryption - The estimated time that is indicative enough to have a clear sense of an automated behavior - 60 seconds

These are rough time estimations that may vary.

Finally, we can now define our rule in simple words.
We would like to find suspicious modification patterns that are made per file within up to 5 seconds, that happen to at least 10 files within 60 seconds.

Detecting a staged data theft and remote encryption
In this form of attack, we must differ between the stages, but each must still have all the operations as seen in an immediate ransomware execution.

• Content Retrieval stage
  1. Single file encryption - The estimated time that takes to read a single file - 3 seconds
  2. Multiple files encryption - The estimated time that is indicative enough to have a clear sense of an automated behavior - 60 seconds
• Content Modification stage
  1. Single file encryption - The estimated time that takes to upload encrypted content and revoke restoration options of a single file - 5 seconds
  2. Multiple files encryption - The estimated time that is indicative enough to have a clear sense of an automated behavior - 60 seconds

These are rough time estimations that may vary.

However, this time we must also take into account the time interval between the stages.
For the purpose of threat hunting, a week should be a satisfying time interval.

Finally, we can now define our rule in simple words.
We would like to find suspicious modification patterns that are made per file within up to 3 seconds, that happen to at least 20 files within 60 seconds in each stage, with up to a week between the stages.

Blind spots

1. During the thesis exploration, we picked time and count estimations as requirements for the threshold. Attackers may execute the ransomware process in a ‘slower’ mode, that doesn’t hit the thresholds. In that case, ransomware attacks may not trigger an alert.
2. The thesis currently assumes that encryption is not an offered action by Microsoft API, Unlike AWS which allows encrypting files using a key management service. In case Microsoft offers this feature in the future, OneDrive ransomware workflow may differ, as it makes it easier to encrypt files using built-in features.

Recommended investigation flow

Once a suspicion is raised using this detection methodology, it is important to respond in Two tasks in parallel:

• Track the source of the activities
• “Manually” confirm the encryption of the volumes

The following questions will help in scoping the suspicion and accurate our response:

• Track the source of the activities
  1. Who is the registered user that executes the suspicious activities?
  2. Were the activities made by the user itself or by an application on his behalf?
  3. What interface was in use during the activities? Such information can be obtained by retrieving the user agent and application ID.
  4. What other activities were made by the user \ on behalf of the user in the same session? These activities can be tracked using session ID (if exists) or by scoping the relevant activities in an estimated time frame.
• “Manually” confirm the encryption of the volumes
  1. Do all file names have the same extension added to them, suggesting an encryption occur? (e.g. revenues23.docx.enc)
  2. Do applications crash \ fail to load file content from the encrypted volumes? A quick check can be done by trying to open files of formats like PNG, PDF, CSV, DOCX, etc.
  3. Were there any ‘ransom notes’ left by the suspected threat actor?

Ransomware is one of the most impactful cyber attacks today. Once a ransomware attack occurs, it is important to respond according to organizational security playbooks.
Such playbooks usually include:

• Relevant security personnel informing, with Crisis Management team involvement
• Regulatory actions such as authorities informing
• Technical data collection and restoration instructions

Suggested playbooks can be found in Microsoft documentation:

Ransomware general response playbook
https://learn.microsoft.com/en-us/microsoft-365/security/defender/playbook-responding-ransomware-m365-defender?view=o365-worldwide

OneDrive data restoration
https://support.microsoft.com/en-gb/office/restore-deleted-files-or-folders-in-onedrive-949ada80-0026-4db3-a953-c99083e6a84f

Hunting queries

The gist contains threat-hunting queries for both forms of ransomware execution as discussed (Immediate + Staged execution)
https://gist.github.com/axon-git/97db00f34f5a040c9f009e553a308fdd