{
	"id": "c16a6b1a-3b05-46b4-859e-3fe626d8ae80",
	"created_at": "2026-04-06T00:21:59.968853Z",
	"updated_at": "2026-04-10T03:20:48.786517Z",
	"deleted_at": null,
	"sha1_hash": "9c8124091169047c1db41bdc4c83bb08861c2f78",
	"title": "The Hunt to Find Origins of Kaseya's VSA Mass Ransomware Incident",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1864486,
	"plain_text": "The Hunt to Find Origins of Kaseya's VSA Mass Ransomware\r\nIncident\r\nBy John Hammond\r\nPublished: 2021-07-20 · Archived: 2026-04-05 22:55:04 UTC\r\nKaseya has a customer base of roughly 35,000 businesses and organizations. These consist of approximately\r\n17,000 managed service providers, 18,000 direct/VAR customers and a significant number of end users at the\r\norganizations they support. There is certainly a large attack surface offered to threat actors who might compromise\r\nthe Kaseya VSA software.\r\nIn the recent ransomware incident that occurred in July 2021, the industry learned that 50-60 MSPs and their\r\nmanaged customers were encrypted by the REvil ransomware gang through the Kaseya VSA remote monitoring\r\nand management software. \r\nWith just 50-60 MSPs affected out of a potential 17,000 or 35,000, that leaves us with a large lingering question…\r\n“Why weren’t there more victims?”\r\nThat is to say, in a more pointed manner, “Shouldn’t there have been more carnage?”\r\nBut Didn't Kaseya Shut Everything Down?\r\nImmediately after recognizing the attack, Kaseya took action to shut down their VSA SaaS platform and instructed\r\ncustomers to shut down all on-prem servers around 1400 ET. This shutdown could be used as an explanation for\r\nwhy such a small number of VSA customers were affected by such a serious and widespread vulnerability.\r\nHowever, there are two important things to consider here.\r\nFirst, according to Kaseya, the SaaS platform was not vulnerable to the exploited vulnerabilities. The shutdown of\r\nthe SaaS platform was a reactionary measure taken out of an abundance of caution but should not have directly\r\nimpacted the number of exploited victims.\r\nSecond, the threat actors synchronized this attack to occur at 1230 ET on July 2. This means that initial\r\nexploitation of VSA servers took place prior to the shutdown. We observed suspicious Kaseya procedure\r\nexecution as early as 0109 ET on July 2. By the time VSA customers shut down their servers, any exploitation\r\nwould have already been complete, and attacks would have happened as planned. Anecdotally, we have received\r\nreports of some customers finding remnants of the malicious stored procedures when bringing VSA servers back\r\nonline; however, any order to shut down after 1230 ET would not have minimized the number of compromised\r\nMSPs.\r\nThe Attack Chain\r\nhttps://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nPage 1 of 5\n\nHuntress, in addition to other industry players, has observed that the ransomware incident used an attack chain\r\nconsisting of (1) an authentication bypass, (2) arbitrary file upload and (3) remote code execution.\r\nWhat we and others still wonder is how did the hackers get the necessary information to bypass\r\nauthentication?\r\nFollowing the exploitation steps, the first malicious request was to the public-facing file /dl.asp.\r\nThis file contained a logic flaw in the authentication process. If a password was not supplied, but a valid unique\r\nKaseya agent identifier (an Agent GUID) was, the end user would be logged in successfully. At that point, the\r\nactor could access other functionality that required authentication—all without a traditional password.\r\nIn the analysis of the attack, we have seen and confirmed malicious access by just providing a unique agent\r\nGUID. We had not seen any indicators that the threat actors brute-forced agent GUIDs; they simply knew these\r\nprior. There were no failed attempts present in any logs.\r\nBut still, there are lingering questions: How did the threat actors have a unique Agent GUID?\r\nWe believe there are a few potential options.\r\nThe Options\r\n1. Threat actors predicted a valid Agent GUID or Display Name.\r\n/dl.asp can accept either an Agent GUID or a Display Name. However, the Display Name (e.g.\r\nvsahost.root.kserver) is not the actual hostname, varies from organization to organization (with no standard across\r\nKaseya VSA usage) and does not appear to be predictable. As for the Agent GUID, it is a randomly generated 15-\r\ncharacter string that is also not based on the hostname in any way. Based on the logs we observed from the\r\nincident, we did not see any indication of attempted brute-forcing of the Agent GUID or Display Name.\r\nExcerpt from /dl.asp showing acceptance of either Agent GUID or Display Name\r\nhttps://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nPage 2 of 5\n\nExcerpt from agent creation showing random generation of new Agent GUID\r\nBased on these details, we have low confidence that the attackers were able to repeatedly predict a valid\r\nAgent GUID or Display Name on their first attempt.\r\n2. Threat actors created a new “rogue” agent and used that new Agent GUID.\r\nThe intended purpose of the original /dl.asp file is to create and download a new agent installer. The default agent\r\ninstaller is available for download without authentication. After successful installation, the user will have access to\r\na new and valid Agent GUID for the newly registered device.\r\nIn the logs we have, we identified a suspicious agent that registered at ~0100 ET, which could have been the\r\nmalicious agent. However, we didn’t have the content of the requests or a packet capture to verify how that agent\r\nwas used. This mysterious agent was also deleted from the database we received, which is also suspicious. It\r\nseems unlikely that an MSP would register an agent at 0100 ET on the Friday of a holiday weekend.\r\nAlthough the Huntress ThreatOps team could not find definitive proof that a “rogue” agent was registered, we feel\r\nthis option is a plausible scenario. However, it’s worth asking “Why didn’t the threat actor compromise more VSA\r\ncustomers?” if this method was (ab)used.\r\n3. Threat actors compromised a host running a VSA agent and used that Agent GUID.\r\nIf the threat actor already had access to a host managed by VSA, they could have retrieved its Agent GUID from\r\nthe registry and then used that for the authentication bypass.\r\nhttps://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nPage 3 of 5\n\nLocating Agent GUID via Local Registry\r\nAlthough we haven’t discovered evidence to support this theory, this option is certainly possible and could explain\r\nthe relatively small blast radius we observed during the attack. Requiring initial access to a compromised host\r\nrunning a VSA agent is an interesting dependency which would make this a much more sophisticated and\r\norganized attack.\r\n4. Other known/unknown vulnerabilities were used to leak an Agent GUID.\r\nWhile there are seven vulnerabilities that were disclosed by DIVD and Kaseya has publicly patched, there is still a\r\npotential for more. \r\nWith that said, even the publicly identified vulnerabilities could include capabilities that might offer a valid Agent\r\nGUID.\r\nNotably, these are the interesting vulnerabilities that might leak information:\r\nCredentials leak and business logic flaw: CVE-2021-30116\r\nSQL injection vulnerability: CVE-2021-30117\r\nWhile strict SQL injection was not observed in the logs, just as with the other possibilities, it could have been\r\ndone long before the actual exploitation and potentially from different IP addresses.\r\n5. Agent GUIDs or Display Names were already publicly accessible information.\r\nIt is no secret that in recent years, Kaseya VSA has fallen victim to security incidents. There have been dumps\r\nshared on Tor Hidden Services and the corners and crevices of the “dark web,” and while we have not been able to\r\nconfirm this, there is the potential that Agent GUIDs were already out and about.\r\nIf this were the case, there would need to be a mapping between the Agent GUID and the respective organization.\r\nIf that information were included in a leak, that could provide all the information necessary for the authentication\r\nbypass. If that mapping was not present and the threat actor had access to just solely Agent GUIDs, correlating\r\nthem to the specific organization would be much harder to do.\r\nSo Now What?\r\nhttps://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nPage 4 of 5\n\nWe acknowledge this is purely discussion and speculation. Considering the gravity of this widespread ransomware\r\nattack, we have to ask “Why was this constrained to only 50-60 affected MSPs, and why not more?”\r\nWe hope that outlining these potential ideas on the origins of this attack showcase the level of exploration and\r\nunderstanding vendors and customers should be seeking—but also raise the notion that this could have been\r\nmuch worse.\r\nWere there other vulnerabilities we were unaware of? Was there missing intelligence in Screenshot.jpg that might\r\ntell more of the big picture? Were multiple agent GUIDs previously leaked or already public information? Did\r\nthreat actors learn from previous incidents (like Colonial Pipeline) that a much larger impact might invite\r\ngovernment intervention? We just don’t know.\r\nIf any organizations have a full copy of this malicious Screenshot.jpg, please share your findings\r\nand the file with us at support[at]huntress.com.\r\nWhat we do know, however, is that the blast radius for this incident was significantly smaller than what it could\r\nhave been. When headlines and news articles fly claiming this is the “biggest ransomware attack so far,” the\r\nindustry has to hone in on that key component: \"so far.”\r\nWe can be thankful that this attack was relatively limited, but we can’t lose sight and not dig deeper to understand\r\nwhy so we can be better prepared for whatever the next threat is. What’s lurking around the corner might just be\r\nworse…\r\n* Special thanks to fellow Huntress Security Researchers Caleb Stewart and Dave Kleinatland for their input and\r\nhelp in preparing this article.\r\nSource: https://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nhttps://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.huntress.com/blog/security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident"
	],
	"report_names": [
		"security-researchers-hunt-to-discover-origins-of-the-kaseya-vsa-mass-ransomware-incident"
	],
	"threat_actors": [],
	"ts_created_at": 1775434919,
	"ts_updated_at": 1775791248,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9c8124091169047c1db41bdc4c83bb08861c2f78.pdf",
		"text": "https://archive.orkl.eu/9c8124091169047c1db41bdc4c83bb08861c2f78.txt",
		"img": "https://archive.orkl.eu/9c8124091169047c1db41bdc4c83bb08861c2f78.jpg"
	}
}