Final nail in the coffin for agent based RMM?

Guest post by Jon Abbot, CEO at ThreatAware

As you are probably aware, Kaseya has become the latest Remote Management and Monitoring (RMM) solution to suffer a ransomware attack.  The previous attack on an RMM on a similar scale was Connectwise Automate.  There was also the Solarwinds Orion hack, another monitoring tool heavily used by many MSPs.

It’s still early days, so we don’t know the full scale of the attack on Kaseya. As it stands it, it would appear that 50 of their on-premise clients, with a total of 1,500 downstream customers, have all suffered a ransomware attack by REvil.

Details of the attack

Cybersecurity company Huntress, who were heavily involved in helping Kaseya, provide a very detailed explanation of the attack.  The attack started by bypassing authentication via a flaw in their authentication progress and then an SQL injection.  From there the attackers worked on a way to push through their malicious code.  That part of the attack must have taken a long time to devise because they appeared to understand the workings of the Kaseya system very well.

Could Kaseya have done more?

Whenever there is an attack of this size, companies commonly use the defence that hindsight is a wonderful thing and if only they had known about that vulnerability before.  However, is there any evidence that they were regularly looking for vulnerabilities?  This is their statement about bug hunting:

Bug Bounty
We’re appreciative of the research community and welcome productive cooperation in eliminating threats, vulnerabilities or exploits. At this time Kaseya does not offer compensation for vulnerabilities that are disclosed. We will, from time to time, say thank you for new and interesting reports in our thanks section of this page. Please note however that providing a report does not guarantee a credit.

How regularly were/are they running vulnerability assessments and penetration tests on the apps?  It seems interesting that Huntress investigated it briefly and found the faults in the code within a day.

Creates more questions than answers?

I would like Kaseya to really help the MSP community and provide more detail.  For example, how many MSPs were affected? Of the ones affected, did they all get the malicious updates? Or, more importantly, did some get the malicious update, but because of their additional security, were they able to defend themselves?

If the authentication was bypassed, did it bypass even if they had 2FA on?  How is the admin login locked down, and can it be restricted by IP or VPN?  If we had these answers, we could all better protect ourselves in the future.

Could the MSPs have done more?

This is a tough question to answer. Looking at how the attack happened, the attackers took over services that would have been trusted.  However, I am curious, would one of the most advanced Endpoint Protection and Response (EDR) solutions on the market have noticed the odd behaviour and protected the operating system? Perhaps this did happen, and some customers were protected because of their EDR?

There is one thing that would have stopped this attack for the MSP, and that’s Applocker.  What this does is only allow pre-approved applications to run on the operating system.  It is absolutely brilliant and yet it is a tool that is commonly overlooked.  The downside is it takes a long time to setup and to maintain, however if these types of attacks continue, this time-consuming solution may be worth it.

Is there a better way?

Is this the start of the end of a centrally controlled, agent based RMM?  Let’s dig into this further. Why, crucially, is this technology a prime target for cyber criminals? The reason is if they can take over the agent, they can run whatever they want.  It isn’t the same as anti-virus for example, because the anti-virus doesn’t run scripts.

At ThreatAware we have designed a fully agentless, endpoint and external security monitoring and management solution.  Our design connects to all your security consoles via secure API connections and our system analyses each of the systems for any issues with the underlying product.  It aggregates, aligns and de-duplicates the data to pick up additional risks, which are impossible to see by looking at the products in isolation.

The data that security products such as anti-virus, patching systems and web proxies gather are vast so that a rich picture of your endpoints and security landscape can be painted.  This is exactly what ThreatAware does, giving you a simple view of a complex issue so you can make the best decision about how to project your company and your clients.

The agentless design is beneficial in so many ways, and this RMM agent risk only makes the argument for switching, even stronger:

1. It finds all the computers you know, and those you don’t, as it locates and identifies computers which access your corporate data, not just your security tools.
2. It gives the most accurate status of each tool because it talks to the console, not the agent.  If the console is not reporting an issue, then the agent is functioning correctly.
3. If one of your underlying tools gets breached and you need to switch it out, simply select a new tool and install it, allowing the monitoring to remain seamless.

This, combined with hardening your endpoints so they only run what you allowed, is the perfect balance of control and security.

If you are interested in learning more about how companies are now moving to an agentless model for cybersecurity monitoring and management, please do reach out.