Secplicity – Security Simplified

MSPs Beware: Attackers Targeting MSP Infrastructure to Install Ransomware

In the past two weeks, sophisticated threat actors have targeted managed service providers (MSPs) and Cloud service providers (CSPs), intending to install ransomware within their infrastructure and customer base. Often, these attacks specifically target products and services MSPs use, such as ConnectWise/Kaseya software, the Webroot Management Console, RDP services and more. Though we’ve seen MSP attack campaigns begin much earlier this year, this malicious activity recently progressed with a new batch of attacks that have affected a large number of MSPs, large and small. Whilst these attacks have nothing to do with WatchGuard or our technology, we take the security of our partners very seriously. As such, we’re releasing this alert to fully inform you of these advanced attacks so you can take the actions necessary to protect your organization and your customers. We recommend you take these targeted attacks very seriously.

Latest MSP Attacks Deliver Sodinokibi Ransomware

Over the past few weeks, we’ve seen fresh reports of advanced threat actors compromising MSP organizations to install ransomware on all of their customer networks, and their computers as well. More importantly, we’ve heard directly from one of our partners who was affected by this attack, and have analyzed some script samples and malware from that incident. At a high-level, the MSP threat actors are leveraging a combination of weaknesses in MSP authentication practices, unauthorized access to MSP management tools, and general lack of certain security controls to install the Sodinokibi ransomware on as many computers as possible. Reports suggest the attackers can even exploit remote management and monitoring (RMM) platforms against MSP businesses to distribute the ransomware to customer endpoints directly.

We’ll cover these recent attacks in more detail shortly, but it’s important to know this isn’t the first campaign we’ve seen targeting MSPs this year. These attacks began in earnest February 2019, and the U.S. government even warned about them earlier. To better understand this class of MSP attacks you should be aware of all the earlier incarnations. With that in mind, let’s look at a quick timeline.

2019 MSP Attack Campaign Timeline

Sodinokibi MSP Attack – Technical Details

At the time of writing, the community hasn’t identified a common root cause or initial entry vector for these MSP attacks. As with many targeted attacks, the sophisticated threat actors behind them often leverage different, customized tactics to compromise different victims. Some advanced tactics include spear-phishing emails, network service exploitation, and credential theft.

Though we don’t know the initial entry vector, these MSP attacks do share many technical details in common, including some that might suggest the entry vector. Furthermore, understanding the technical details can help you identify and protect yourself from the attack. Let’s explore these technical commonalities below.

  1. The attackers target RDP. The Remote Desktop Protocol (RDP) is a Microsoft network standard that provides remote desktop management capability in Windows. Many MSPs commonly leverage RDP to manage their clients and their own desktops, and often expose the RDP services externally. Some reports suggest these threat actors gained initial access to MSPs through RDP services. We imagine two likely scenarios. One common tactic is RDP brute-forcing, where attackers automate many login attempts using common credentials, hoping one hits. The second involves exploiting a software vulnerability to gain control of an RDP server. For instance, attackers could exploit the recently patched RDP vulnerability called BlueKeep (CVE-2019-0708) to gain complete control of an MSP’s unpatched RDP servers. In any case, once an attacker owns an RDP server, it makes an ideal position to steal or acquire other privileged credentials.
  2. The attackers obtain your privileged credentials. Whether via the RDP vector mentioned before, or some other initial attack, the first thing these attackers do is try to obtain as many privileged credentials as possible. Once they have access to legitimate MSP user accounts, they can use your tools as though they were those users.In WatchGuard’s quarterly Internet Security Report, a malware tool called Mimikatz has remained the top volume threat for over a year. Mimikatz is a tool attackers use specifically to steal credentials once they’ve compromised one of your systems. While it hasn’t been reported in these attacks, it offers one example of how attackers might obtain privileged credentials once they’ve hijacked an MSP system.
  3. The attackers leverage common MSP tools to deploy Sodinokibi. These sophisticated attackers have studied MSPs and understand the tools they use. In fact, they even use those tools against you to deploy their malicious payloads. As previously mentioned, the earlier MSP attacks literally exploited a software vulnerability in a common ConnectWise/Kaseya plug-in used by many MSPs. That particular attack succeeded without any user interaction or stolen credentials.However, the more recent attacks are different. Once the attacker obtains one of your privileged MSP accounts, they can legitimately leverage your RMM, or other MSP tools, directly; without relying on a vulnerability. Most of these tools have features that allow you to deploy software or run commands on all the endpoints you manage. Researchers have specifically seen these threat actors leverage the ConnectWise Control and Kaseya VSA RMMs in this way. This isn’t due to any flaw in the RMM itself, but simply the attackers’ access to your privileged credentials.
  4. Delivering Sodinokibi via Webroot’s management console. This detail is directly related to the point above, but we believe it deserves individual emphasis as a relatively new development. In the most recent MSP attacks, the attackers specifically leveraged the Webroot management console to deploy their malicious scripts and ransomware to managed endpoints. Like above, this isn’t due to any flaw in the Webroot system but simply the attacker’s access to privileged credentials. The attackers specifically leveraged this privileged access to launch malicious PowerShell commands on all an MSP’s managed endpoints at once, as seen in the screenshot below.

    Figure 1: Logs from the Webroot Management Console, which was used to launch a malicious PowerShell command. Image credit to @chrisbisnett from @HuntressLabs

  5. They disable your security controls. The attackers can also exploit their elevated access to your RMM and security management consoles to disable the security controls you so rigorously implemented. For instance, they might use the Webroot Management Console to disable some of the endpoint security features before installing ransomware. Reports suggest the attackers disable antivirus clients, and in some cases, they also disabled the Veeam endpoint backup agent to prevent data recovery. In short, if an attacker has one of your administrative management credentials, they can use your legitimate RMM solutions to remove the security you so carefully added.
  6. Heavy use of PowerShell and the PowerSploit framework. Like past MSP attacks, the recent ones use PowerShell to download staged payloads, and likely to help their malware evade legacy security controls. The attacker specifically uses functionality from a well-known PowerShell penetration testing framework called PowerSploit, which is commonly used by cyber criminals. Specifically, they use a PowerSploit script that reflectively injects a DLL or EXE into another process, or the Powershell process itself. This effectively loads the executable in memory only, as fileless malware. As an aside, we’ve analyzed the samples we acquired from this attack and can confirm WatchGuard’s anti-malware services (like Gateway AntiVirus and APT Blocker) detect the malicious PowerShell script samples associated with this attack.
  7. Installs the Sodinokibi ransomware on as many endpoints as possible. Simply put, the whole point of this attack is for the threat actors to load the Sodinokibi ransomware on as many of your, and your customers’ endpoints as possible, in hopes of extorting you for a large sum of money. The sample we acquired from one of these attacks looks like a pretty common variant of Sodinokibi, which all three of WatchGuard’s anti-malware services catch when sent over a network connection. However, know that the attackers’ use of PowerShell to stage their payload delivery could help the malware evade security controls.In the end, Sodinokibi is pretty typical ransomware. It strongly encrypts your files and then points you to a Dark Web (Tor onion) site to learn how to pay the ransom and recover your files. The ransomware does have some evasive capability that might help it elude some anti-malware sandboxes, but WatchGuard’s APT Blocker does catch those behaviors. If you’d like to know more about Sodinokibi, we recommend you read this post.

Now that you understand some of the common technical details about these attacks, it might help to take a more detailed look at the anatomy of an attack.

Anatomy of Sodinokibi MSP Attack

  1. Gain access to an MSP’s privileged credentials. This is the only unclear step in the attack, as the community hasn’t yet identified any shared root cause for the initial infection vector. As in most targeted attacks, the adversary often uses many different techniques to compromise different victims depending on their individual weaknesses. That said, open RDP services seems to be a common weak point. It’s quite possible the attackers are brute-forcing credentials from an open RDP server, or leveraging a potential RDP flaw (like one targeting the BlueKeep vulnerability) to gain control of your RDP server and steal credentials using other tools. It’s also possible that attackers still use the old ConnectWise/Kaseya plug-in vulnerability to gain access, though we suspect most MSPs patched that in February. They may even use simple spear-phishing emails to trick your users out of their credentials. In any case, we know that the attacker gains enough access to an MSP’s infrastructure to obtain some privileged credentials.
  2. Leverage MSP management tools. As mentioned above, the reason these attackers obtain your privileged credentials is to abuse them on your RMM system. Once they have credentials, the threat actors log into RMMs like ConnectWise Control, Kaseya VSA, or Webroot’s Management Console and directly manipulate your managed endpoints. They often start by disabling security features and software, like the aforementioned Webroot AV, ESET AV, and Veeam backup agents.
  3. Launch a batch script or PowerShell from your RMM or management consoles. Once they have access to your RMM or a management console, they can directly deploy commands or software to all managed endpoints. Reports suggest they have used the Webroot Management console in some of these attacks. Using your MSP tools, they can directly launch their first PowerShell command either as a batch script (1488.bat) or a command (as seen in Figure 1 above). Here’s an example of the command they use:
    
    

    In a nutshell, that command uses the Windows command line utility (cmd.exe) to start PowerShell in a hidden mode, with fewer local restrictions. The actual contents of the PowerShell are base64 encoded. Here is the decoded script:

    
    

    That script checks whether the endpoint is a 64-bit system or not and sets environmental attributes accordingly, then it downloads the contents of a Pastebin page as a string, which it runs with PowerShell as the second stage of the attack. At the time of writing, the malicious script had been removed from Pastebin. However, we obtained a sample from a victim, and have shared a very small excerpt of the very large script below.

    
    

    Our analysis of the full script found that this is a slightly altered version of a script from the PowerSploit collection called Invoke-ReflectivePEInjection. It’s designed to directly inject a DLL or EXE into a running process, or the PowerShell process itself. This effectively loads that executable in memory only, as a form of fileless malware. In this case, the script specifically contains the embedded portable executable (PE) file for the Sodinokibi malware, which encrypts the victim computer as expected. As an aside, our Gateway AntiVirus (GAV) service does recognize both the initial and secondary PowerShell scripts as malicious content.

To summarize, these targeted attackers leverage different tactics to gain privileged MSP account credentials. Using those credentials, the attacker can directly leverage your RMM or endpoint management systems to deliver malicious PowerShell script to all managed endpoints. The staged PowerShell script loads the Sodinokibi ransomware directly into memory as fileless malware. Leveraging your own tools, the attackers can infect all the computers you manage at once.

What Can MSPs Do to Protect Themselves?

First, there is no silver bullet defense, especially where sophisticated attackers are concerned. These advanced threat actors leverage many techniques to evade traditional defenses, so you need different layers of security to combat different attack methods. That said, there are some key defenses that really stand out in this case.

As technically complex as some parts of this MSP attack are, at its core it’s essentially a credential theft. Authentication is the cornerstone of all security. If an attacker can masquerade as you, they can do anything you’re able to. The best way to secure authentication is MFA. You should deploy it internally and at your customer sites.

Additional Resources

Recent MSP Attacks

February MSP Attacks