By now you have no doubt heard about the Kaseya ransomware attack. And you want to know: does it affect my organization? Hopefully, the answer is “no”. However, a little planning goes a long way in cyber security. And you may want to respond to the Kaseya ransomware attack even if it did not directly affect your organization. Let us look at the ransomware attack and move on to the actions you will likely want to take.

What is Kaseya?

Kaseya VSA (Virtual System/Service Administrator) is a remote monitoring and management tool. Device support providers like to use remote monitoring and management tools (RMMs). Why? Because they automate and scale the device management process without adding labor costs. These tools typically work by installing a small software agent on the device. The agent then talks to the device management application on the server side.

How Did the Kaseya Ransomware Attack Take Place?

The Revil ransomware group exploited a vulnerability in the Kaseya VSA software. They were able to establish a session without properly authenticating to the Kaseya server. Once the session was established, Revil were able to upload a ransomware executable that would then be pushed to all the Kaseya VSA servers. The Kaseya VSA servers then downloaded the ransomware executable, mistakenly believing it to be a software update to be deployed.

Once installed, the executable disabled Windows endpoint protection. It encrypted the files on the device. Then, it changed the user’s splash screen to a ransomware message. Finally, it deposited a readme file that contained instructions for paying the ransom and receiving a decryption key in return. Revil was demanding $45,000 in cryptocurrency in exchange for providing a customer the decryption key. Revil also said they would provide the decryption key for all affected systems worldwide for a payment of $70 million.

I see two troubling aspects to the Kaseya ransomware attack.

• Revil was able to exploit the Kaseya supply chain to achieve a ransomware attack at scale. The group infiltrated a single victim, Kaseya. But, they were able to use Kaseya’s supply chain network to extend their ransomware attack to hundreds if not thousands of victims.
• The ransomware was delivered in an automated way and originated from a server that would normally be trusted by a customer’s network.

Was Your Organization Affected?

So, what is your appropriate course of action to respond to the Kaseya ransomware attack? The first thing you want to sort out is whether your organization is a victim of this ransomware attack.

• Do you contract with a service provider to handle device management? Does the service provider use Kaseya VSA? If so, it is possible that your devices have been compromised.
• Do you contract with a service provider that uses an RMM tool different from Kaseya VSA? If so, your organization is not a victim—yet. It is possible that attackers will compromise your service provider’s RMM tool in the future to deliver their ransomware. So, you are safe for now. But you should still be concerned about the integrity of the RMM tool used to manage your endpoint devices.
• If you handle device management using your own resources and tools, then you are not a victim. However, I encourage you to review how you have configured your endpoint management tool. You will want to be looking for any potential security weaknesses that an attacker could exploit to launch a ransomware attack.

Ransomware Attack Precautions You Can Take if You Use a Device Management Provider

If you are the customer of a device management provider, have a discussion with them about their security protocols. Do they have contingency plans to isolate and remediate their RMM servers in the event of a ransomware attack? How quickly will the provider notify you that a ransomware attack has taken place? And how will they notify you?

Talk to your device management provider about slowing down the automated delivery of software updates. Ask your provider to show you test results that confirm the integrity of the delivered update before you authorize a push to all managed devices.

You might consider downloading the software update to a single machine that is not connected to other machines. Wait 24 hours to see what happens with that update before authorizing rollout to all your other devices. Admittedly, this is a crude method. However, it would offer you some protection against ransomware attacks without requiring you to conduct a lot of testing.

Steps Everyone Can Take in Light of the Kaseya Ransomware Attack

As troubling as this attack is, remember that most attacks are going to come through the “front door”. Meaning, 94% of network attacks will take place through phishing. So, do not forget to continue with your regular program of phish training and testing.

Make sure your backup and restore plan is tested and fully operational. It will cost you far less to set up a backup and restore plan than it will to pay a ransomware attacker. Make sure that the target for your backup is not connected to the rest of your network.

Set up some kind of endpoint management for your company devices. You want to have a path to gather telemetry from the devices that can give you an early indication of ransomware activity. For instance, what if more than one device reports the presence of a previously unrecognized filetype? That could indicate the device files are being encrypted.

Think about conditional access policies you can create that would halt or slow the spread of a ransomware attack across your network. For instance, if you see that a device is attempting to connect to other network devices after hours, that seems suspicious. You could set a response to block such access. Understand the behavior of these ransomware attacks and create policies that would look for similar behaviors in your network. If you see these behaviors, take action to block the behaviors and limit the spread of a ransomware attack.

You Own Security

These supply chain attacks are requiring IT managers to reconsider their software landscape. Of course, they must manage the applications and operating systems in use in their networks. But IT managers now must also ask the partners in their supply chain about how they are managing security for the software they use. You cannot–and should not–take security responsibility for all the software that is used in the supply chain supporting your organization. You can, however, hold your service providers accountable for properly managing the security of software they use to provide services to your organization. Do not be afraid to hold their feet to the fire!