Everyone loves the holidays. Time off from work, and a quiet afternoon the day before the holiday, makes for a relaxing long weekend for most. But hackers are fully aware that they’ll get plenty of extra time to perpetrate their attacks while people aren’t watching.
This July 4th weekend, they chose to exploit a critical vulnerability in Kaseya’s VSA software. As with many cyberattacks, it started Friday afternoon, with the attackers hoping they would have all day Saturday, Sunday and the holiday Monday to inflict as much damage as possible on more than 1,000 companies and approximately a million computers before being noticed.
It’s an MSP’s worst nightmare. Dealing with a single cybersecurity incident is extremely difficult and stressful; dealing with cybersecurity incidents at every single client, as well as internally, however, is absolute chaos.
There is no doubt about it: Kaseya’s breach is not going to be the last supply-chain attack we see. In order to protect our clients from cyberattacks, we need to protect ourselves.
Related: Cybersecurity Basics for Business in 2021
The good news about the Kaseya vulnerability is that only a small percentage of Kaseya VSA servers were compromised. That limited the damage to “only” around 1,000 companies. This means that some MSPs were able to protect themselves and their clients, despite a huge security flaw in the software they were using.
In order to answer the question of how to protect ourselves, it’s best to start by looking at who didn’t get attacked—and why.
Whitelisting
The first step in the support playbook that most software companies seem to use is “whitelist these folders in your antivirus,” regardless of what the issue is. Hackers are smart enough to try running viruses, masquerading as legitimate software, inside of commonly whitelisted folders.
Even worse, if you’ve whitelisted your RMM tool in your antivirus software, you’ve given hackers free rein to perform malicious activities, en masse, without even being scanned. Whitelisting by path is a terrible practice; it should be avoided.
Proof statement: Many MSPs that did not whitelist the Kaseya directory in their security tools were not affected by the attack.
Next-Generation Antivirus
Traditional antivirus tools compare files to lists of known malicious software and block them when a match is found. Hackers have figured this out. They deliver their attacks in more advanced ways that can’t be stopped just by looking at a file hash. “Next-Generation Antivirus,” or AV that’s based on behaviors, will look at what is actually happening and decide if it looks dangerous.
To illustrate this, there are numerous ways you could write a program to encrypt files on a drive. It would be nearly impossible to enumerate every possible way that program could be written. However, by blocking the activity of encrypting files, you’re blocking the dangerous behavior itself.
AI and machine learning-based antivirus products generally accomplish this very effectively. They operate in a manner similar to the way humans think. I showed my toddler pictures of different breeds of dogs, and, after he saw a few pictures, he could identify the animal as a dog even if I showed him a completely different picture that he had never seen before.
The AI engines are fed known malicious software and analyze the behavior of that software; after ingesting enough data, they learn patterns and activity that they can use to judge new software that they have never seen before.
Proof statement: Several next-generation antivirus products were capable of identifying the encryption activity from the attack. Therefore, they would have prevented it.
Script Control
In the Kaseya attack, antivirus products that lacked script-control functionality had no chance of blocking the attackers. In fact, a large percentage of malicious activity is now executed through scripting (e.g., PowerShell, Office macros, etc.).
Proof statement: Several endpoint security products with script-control capabilities were capable of stopping the Kaseya attack.
Zero Trust
Zero trust goes a step further than whitelisting. It’s the ultimate tradeoff of security versus convenience. But it’s also the difference between spending hundred-hour (or longer) weeks, week after week, recovering from an attack and sleeping well at night. Zero Trust means blocking by default and only allowing known good things to run. Obviously, the ransomware in the Kaseya attack was not considered a “known good” script.
Proof statement: MSPs that utilized properly configured Zero Trust software were not affected by the Kaseya attack.
Other Security Measures
Although security practices like multi-factor authentication and least privilege would not have prevented this breach, they’re still important to implement as they are likely to protect against some future vulnerabilities.
Here are some additional tips:
- Ensure that log information is preserved and, ideally, monitored for suspicious behavior.
- Separate backups. This means the backups should not be accessible from the same tools that access your customer environments. Use a separate RMM and a separate remote-access tool because, if either is breached, then your customer environments, as well as the backups, will be destroyed. Some backup companies offer “immutable backups,” meaning there is no way to delete the backup.
- Monitor your environments! One of the first things the attackers did was disable Windows Defender antivirus; that’s a typical first step in any attack. Any RMM has the ability to monitor antivirus status, and, although the attack is already underway when this alert comes through, it’s better than not knowing about it for days.
Takeaways from the Kaseya Attack
It’s becoming increasingly important to lock down environments properly. Simply installing security software is no longer enough; rather, we need to critically evaluate what vendors tell us (especially “whitelist our software in your antivirus”) and determine if the settings we’re implementing are truly the least privilege and most restrictive needed to accomplish our goals.
