Although ransomware is often characterized as an attack on a machine where files are stored, it can run on one device while rewriting files somewhere else.
Remote encryption is not always a file server problem. It’s often a workstation issue that becomes a file server problem. If a workstation can reach a share and write to the files, it follows that it can damage them, too.
A file server may itself be secured, but that does not help enough if a compromised workstation has been granted write access to its folders. All an attacker needs is a route to the data.
The question is: Why did that device have access to those files in the first place?
Ransomware does not need unlimited power if the environment gives it unlimited access.
The problem with always-on access
From a ransomware point of view, ordinary write access can be enough to cause a problem. Storage access must be reviewed with the same discipline as application control or privileged access.
Some users only need read access. Some devices should never connect to certain shares. Some support work needs only a short window of access before rights are revoked.
Read access and write access should not be treated as the same thing. Ransomware needs the ability to change files, and reducing unnecessary write access can make a major difference.
Access should come with an expiration date
It’s really a question of policy management.
If someone needs access during working hours, for example, they should have that access and nothing more. Organizations should not permit permanent unrestricted access just because that was easier on the day.
A lot of ransomware damage happens because access is always on. If a share is reachable all day, every day, from devices that do not constantly need it, that’s an unnecessary risk.
Other Zero Trust layers still count
Restricting access to shares is not the whole answer.
Deny-by-default allowlisting and enforceable application control are still crucial, as are other access restrictions.
When the specific problem is remote encryption, the first question is always whether the compromised device should have been able to reach the share in the first place. The useful test is whether every route to a share can be defended in plain English.
If the answer is vague, the rule probably needs work.
Begin by picking the shares that would really hurt if they were encrypted. Then ask who needs to write to them, from which devices, at what times, and why?
If those questions cannot be answered clearly, that access likely needs to be removed, narrowed, or time-limited. The goal is to make sure one bad endpoint can’t become a bad day for the whole organization. That means controlling the route, the permissions, and closing access when it’s no longer needed.
Three steps to reducing remote encryption risk with ThreatLocker
With ThreatLocker, the network constantly looks for proof that a device should be talking to this resource, for this reason, at this time. If there’s no proof, or if the justification is lost, there’s no connection.
Moving the firewall decision closer to the endpoint is key. It’s not enough to protect the edge of the network if an attack is moving between devices and shares internally.
- Find the shares that matter
Identify the file shares that would cause serious disruption if encrypted. For each one, ask who needs access, what type of access they need, which devices should connect, when, and for how long. Allow this to drive secure policy decisions.
- Restrict the route
Use Zero Trust Endpoint Firewall to control device-to-resource access. Avoid broad internal connectivity by default. Permit approved devices to communicate with protected file servers, then narrow that access by purpose, role, and time window.
- Limit what access can do
Separate read and write permissions. Remove standing access where timed access would work. Use Allowlisting to block unapproved software and Ringfencing™ to limit what trusted applications can do if they are misused or otherwise compromised.
Zero Trust Endpoint Firewall is designed to control which devices can communicate with which resources. Applied to remote encryption, the principle is equally blunt.
Being on the network should not automatically give a device a route to the file server. It should be allowed to reach only the resources it needs, not every resource on a network.
FAQs
What is remote encryption?
Remote encryption is a ransomware technique in which malware running on one device encrypts files stored on another system, such as a file server or network share. The ransomware does not necessarily need to execute on the system where the targeted files are stored.
How does ransomware encrypt files on another device?
If a compromised endpoint has write access to a network share, ransomware may be able to use that existing access to modify and encrypt files remotely. This means a workstation with unnecessary access can expose data on an otherwise well-secured file server.
How can organizations prevent remote encryption?
Organizations can reduce the risk of remote encryption by limiting which devices can connect to sensitive file shares, restricting write permissions, removing unnecessary standing access, and using time-based access where appropriate. Application control and network segmentation can provide additional layers of protection.
Why is restricting write access important for ransomware prevention?
Ransomware needs the ability to modify files to encrypt them. Users or devices that only need to view files may not require write permissions. Separating read and write access reduces the number of accounts and endpoints capable of changing sensitive data.
How can Zero Trust help stop remote encryption?
Zero Trust limits access according to what a user, device, or application actually needs. For remote encryption, that can mean controlling which endpoints can reach file servers, limiting what they can access, restricting when connections are permitted, and blocking unauthorized software from executing.
ABOUT THE AUTHOR
Kieran Human is a Lead Cybersecurity Engineer at ThreatLocker. He holds a Master of Science in Cybersecurity and Privacy from the University of Central Florida, where he focused his thesis on cryptocurrency and cybercrime. Kieran applies his deep technical expertise to solve complex client challenges and lead critical product research. A passionate educator, he shares his insights through technical writing, white papers, and webinars.
