Blog

RSS

Kaseya Supply Chain Ransomware Attack

Written by

Ryan Barnett

July 15, 2021

Ryan Barnett is a Principal Security Researcher working on the Akamai Threat ResearchTeam supporting Kona security solutions. In addition to his primary work at Akamai, he is also a WASC Board Member and OWASP Project Leader for: Web Hacking Incident Database (WHID) and Distributed Web Honeypots. Mr. Barnett is a frequent speaker at security industry conferences such as Blackhat and has authored two web security books: Preventing Web Attacks with Apache (Pearson) and The Web Application Defender's Cookbook: Battling Hackers and Defending Users (Wiley).

 

On July 2, 2021, Kaseya disclosed an active attack against customers using its VSA product, and urged all on-premise customers to switch-off Kaseya VSA. Shortly before this alert, users on Reddit started describing ransomware incidents against managed security providers (MSPs), and the common thread among them was on-premise VSA deployments. In the hours to follow, several indicators of compromise (IOCs) were released, and Akamai was able to observe some of that traffic. A patch for the VSA product was released by Kaseya on July 11.

The attack:

The attackers, affiliates of the REvil ransomware group, exploited authentication bypass and arbitrary command execution vulnerabilities (CVE-2021-30116) that enabled them to distribute ransomware encryptors to targeted systems. In order to assist defenders, Kaseya released a number of IOCs related to the ransomware attacks.

Traffic analysis:

Once IOCs are released, Akamai can leverage our wide view into internet traffic and query petabytes of traffic information to identify key patterns and gain insight into attack sources, distributions, and prevalence. We analyzed HTTPS traffic from the Kaseya attack timeline (July 1 until July 6, 2021) flagging any traffic that was accessing the URLs described in the IOC release.

The goal of our analysis was to determine who was scanning for these URLs, and if the traffic was part of a reconnaissance action (target identification) or actual exploitation attempts. The baseline is that GET/HEAD requests would be reconnaissance and identification, while POST requests would be exploitation. What we found was that essentially all traffic was GET/HEAD-based, meaning it was target scanning traffic, and not part of the exploitation attempts.

However, for the sake of transparency, the low number of POST requests could be an indicator that there were no VSA servers behind Akamai's platform at the time of scanning.

Traffic details:

After queries were complete, Akamai identified 372 HTTP requests in our traffic accounting dataset. Virtually all of them were GET requests (97.85%), followed by HEAD (1.88%) and finally POST (0.27%). As mentioned, the presence of GET/HEAD requests suggests that the traffic was centered on identification and not exploitation. We also identified 88 unique IP addresses. Those details are at the end of this post.

Figure 1: A breakdown of the IOC URL accesses from July 1 until Jul 6, 2021 Figure 1: A breakdown of the IOC URL accesses from July 1 until Jul 6, 2021

We included Jul 1, 2021 in our analysis since this was the day before the public release of details by Kaseya. This shows there could have been some amount of normal, benign traffic. What the data also shows is that many organizations took the warning issued by Kaseya seriously, and shut down, or disabled, the VSA software.

Traffic analysis determined that the most common tool being used was Fuzz Faster U Fool, followed by GoBuster. As the name suggests, Fuzz Faster U Fool - or Ffuf - is a fuzzing tool used for identification. GoBuster is used to brute-force URIs and DNS subdomains. Both are popular tools for bug bounty hunters. In this case, the traffic analysis suggests these tools were being used to search for URLs matching the IOC strings in order to locate vulnerable assets.

Conclusion:

While the scanning and analysis covers a small window of time, it is important to stress that vulnerability scanning and target reconnaissance happen constantly. Attackers are scanning and probing your network on an ongoing basis to look for weaknesses.

Supply chain attacks, like the one experienced by Kaseya's MSP customers and their customers, are a nightmare scenario. This is why it is essential that patches be applied as soon as possible and traffic defenses be monitored and tuned properly.

However, in the case of Kaseya, the attack leveraged a zero-day vulnerability, so there was no patch. In these situations, layered defenses, network segmentation, and disaster recovery plans are critical (including segmented backups). Recovery planning and operations should consider scenarios dealing with supply chain problems, including the complete loss of, or disruption to, managed assets.

Akamai's Threat Research Team is continuing to track traffic associated with the Kaseya incident. Additional blog post updates will be made as needed.

Identified IP addresses:

104.200.29.139

113.173.149.48

117.61.242.70

117.95.232.62

122.178.156.152

123.204.13.110

134.122.114.190

143.110.241.135

143.244.128.87

147.182.172.145

151.244.4.153

154.185.203.234

155.138.162.201

156.217.110.66

159.65.228.100

159.89.177.106

161.35.136.251

161.97.70.207

165.22.205.38

165.22.41.30

167.99.49.144

17.253.80.103

175.101.68.80

175.16.145.28

177.86.198.242

178.128.224.80

178.128.28.156

178.239.173.161

180.94.33.200

183.22.250.36

185.195.19.218

185.65.135.167

188.166.61.213

192.254.65.235

192.40.57.233

193.169.30.10

193.56.252.132

194.195.219.144

194.233.64.67

194.44.192.200

194.5.52.4

194.5.53.98

195.95.131.110

196.64.76.3

199.247.23.87

2.16.186.103

2.16.186.86

2.59.134.200

2.59.135.105

2.92.124.237

20.73.12.15

20.73.12.60

20.74.134.159

202.142.79.81

204.4.182.16

207.244.245.21

222.76.0.230

2604:a880:0400:00d0:0000:0000:1d1b:7001

2a01:04f8:010b:0710:0000:0000:0000:0002

2a01:04f8:1c1c:cc87:0000:0000:0000:0001

2a01:7e00:0000:0000:f03c:92ff:fe12:3d0a

2a0d:5940:0006:01d9:0000:0000:0000:7abe

2a0d:5940:0006:01ea:0000:0000:0000:498d

34.132.164.221

34.132.182.60

34.71.132.48

35.202.142.60

35.232.137.16

35.232.55.163

37.220.119.221

45.124.6.219

45.14.71.9

45.86.201.85

46.19.225.91

50.35.184.96

51.83.140.186

52.15.133.71

52.151.244.28

52.188.217.115

52.20.26.200

52.205.190.252

54.37.72.253

66.23.228.62

76.76.14.36

85.203.46.145

89.39.107.195

91.90.44.22

94.68.117.73



Written by

Ryan Barnett

July 15, 2021

Ryan Barnett is a Principal Security Researcher working on the Akamai Threat ResearchTeam supporting Kona security solutions. In addition to his primary work at Akamai, he is also a WASC Board Member and OWASP Project Leader for: Web Hacking Incident Database (WHID) and Distributed Web Honeypots. Mr. Barnett is a frequent speaker at security industry conferences such as Blackhat and has authored two web security books: Preventing Web Attacks with Apache (Pearson) and The Web Application Defender's Cookbook: Battling Hackers and Defending Users (Wiley).