Proposals for shared files attributes to File object

[erikloman]

Remote Ransomware Encrypting Shared Files

INTRODUCTION
Remote ransomware refers to ransomware that operates on an unmanaged (or compromised) remote machine, encrypting files shared from another system. Since the endpoint is unmanaged (or compromised), the attack can only be detected on the system sharing the files.

Remote ransomware is highly prevalent. According to this Microsoft report from 2023:

80-90% of all successful ransomware compromises originate through unmanaged devices

But this is not a new development. In 2013, CryptoLocker was already encrypting files on network mapped drives (Z:), which work similarly to local drives (C:). For applications it is just a drive letter. However, adversaries now face greater challenges in bypassing ransomware detections offered by MDR or EDR products. As a result, they resort to using a foothold machine, which is either an unmanaged endpoint or a compromised endpoint where a security product has been disabled. From this foothold, the ransomware encrypts the files shared from other systems.

SITUATION
A file server shares a local folder 'C:\Shared' with the network. The share is named 'Sales'.
An endpoint accesses these shared files via a network mapped drive Z:\ which is mapped to \\Server\Sales.

WHAT HAPPENS
The endpoint is unmanaged (or compromised) and executes ransomware.
The ransomware enumerates all drives (including the network mapped drive Z: ) and begins encrypting the files.
As a result, all files in the shared folder are encrypted by the endpoint.

The file server runs a security product that can detect the remote ransomware attack on its files and generates a detection_finding event, adding an array of evidence artifact objects.

Evidence artifacts

1. Add src_endpoint Network Endpoint object with ip set to the IP address of the attacking endpoint.
2. Add file File object with type_id set to Regular File (1), for each file that was encrypted.

ISSUES

1. I would like some way to indicate that the File object (as evidence) is a shared file.
2. A single folder that is shared with the network can be shared under one or more names. For example, C:\Shared\ can be shared both as "Workplace" and "Sales". Both share names access that same C:\Shared\ folder. I would like the share name to be recorded so that an investigator knows which share was attacked.

PROPOSAL 1
Add is_shared as Boolean attribute to File object.

The following example shows how this would work as evidence, listing a Regular File and a Folder entry. There is no reference between them. They are just indicating that the file and folder are shared.

Note: The folder has its name attribute set to value Sales, indicating the name of the shared folder that was accessed. I do not know if this is good practice or something that is even allowed? Since it is not stated otherwise, I assume it could be allowed. I would recommend adding a comment to the name attribute of the File object that this could be the name of the share, if this proposal ends up in the schema.

Example:

"evidences" : [
  "file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "is_shared" : 1,
    "type_id" : 1,
    "type_name", "Regular File"
  },
  "file" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "is_shared" : 1,
    "type_id"  : 2,
    "type_name" : "Folder"
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

The goal of the above proposal is to list which files and folders are shared.

PROPOSAL 2
Add Shared File and Shared Folder to type_id enum of File object.

The following example shows how this would work as evidence, listing a Shared File and a Shared Folder entry. Just as proposal 1, there is no named reference between them. They are just indicating that the files and folder are shared.

Example:

"evidences" : [
  "file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "type_id" : 8,
    "type_name", "Shared File"
  },
  "file" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "type_id"  : 9,
    "type_name" : "Shared Folder"
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

The goal of the above proposal is to list which files and folders are shared.

PROPOSAL 3
Add optional share_name attribute to File object to list the name of the share the file was accessed through.

The following example shows how this would work as evidence, listing a Regular File and a Folder entry. The share_name attribute indicates the file was accessed via a share called Sales. Optionally, adding another file object with type_id set to Folder and name attribute set to Sales can help clarify that the share is C:\Shared and not C:\Shared\Leads.

Example:

"evidences" : [
  "file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "share_name" : "Sales"
    "type_id" : 1,
    "type_name" : "Regular File",
  }.
  "file" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "type_id"  : 2,
    "type_name" : "Folder"
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

The idea behind the above proposal is to list the name of the share through which the file was accessed.

PROPOSAL 4
Add shared_file and shared_folder as File object as Evidence artifact.

The following example shows how this would work as evidence, listing a shared_file and a shared_folder as evidence artifact.

Example:

"evidences" : [
  "shared_file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "type_id" : 1,
  }.
  "shared_folder" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "type_id"  : 2,
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

The idea behind the above proposal is that we only have to add to the list of supported evidence artifacts and don't change anything in the File object.

PROPOSAL 5:
A combination of proposal 3 and 4:

Example:

"evidences" : [
  "shared_file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "share_name" : "Sales",
    "type_id" : 1,
  }.
  "shared_folder" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "type_id"  : 2,
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

PROPOSAL 6
We could use the xattributes attribute of the File object and specify the name of the share. However, this attribute serves as a fallback generic attribute to store information that doesn’t fit the schema.

Shared files and folders are common in enterprise environments and I hope we can model this within the OCSF schema rather than resorting to the xattributes attribute.

Example:

"evidences" : [
  "file" : {
    "name" : "Acme Wonders.pptx",
    "path" : "C:\Shared\Leads\Acme Wonders.pptx",
    "xattribute" : { 
        "share_name", "Sales"
    },
    "type_id" : 1,
    "type_name", "Regular File"
  },
  "file" : {
    "name" : "Sales",
    "path" : "C:\Shared",
    "type_id"  : 2,
    "type_name" : "Folder"
  },
  "src_endpoint" : {
    "ip" :  "172.20.0.201",
    "name" : "Endpoint B"
  },
],

CLOSING
Regardless of the proposal we choose, I believe it is important to provide guidance for producers, mappers, and consumers on how evidence of remote ransomware is represented within the OCSF schema. I am willing to provide a post or article on this once we have decided.