Kaseya Supply Chain Ransomware Attack
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 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.
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.
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.
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.
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: