CVE-2021-30116

What it actually does

Kaseya VSA on-premises versions before 9.5.7 expose agent credential material through the default agent download workflow. An unauthenticated attacker can download a Windows agent installer, extract or generate KaseyaD.ini, and obtain an Agent_Guid and AgentPassword. Those values can then be submitted to /dl.asp using query-string parameters to obtain a sessionId cookie. That session can be reused against VSA functionality not intended for agent-originated access, creating an authentication bypass path that can enable further compromise of the VSA server and managed endpoints.

Why it matters to the business

This is a high-impact, internet-exploitable flaw in remote monitoring and management software, a category of tooling that often has privileged access across many endpoints. Because it is listed in CISA KEV, has known ransomware use, and has a high EPSS score, unpatched exposure should be treated as an urgent incident-risk condition rather than routine patching. Successful exploitation can allow attackers to pivot from the VSA server into managed systems, disrupt operations, deploy ransomware, steal credentials, or abuse trusted administrative channels at scale.

How an attack unfolds

An attacker first identifies an exposed Kaseya VSA server and accesses the default download endpoint, commonly /dl.asp. The attacker downloads a Windows agent package without authentication and installs or inspects it to obtain KaseyaD.ini, which contains Agent_Guid and AgentPassword values. The attacker then sends those values back to /dl.asp as GET parameters, such as un=<Agent_Guid> and pw=<AgentPassword>, and receives a sessionId cookie. With that cookie, the attacker can make follow-on authenticated or semi-authenticated requests to VSA services that were not intended to be reachable using agent credentials. In real-world campaigns, this class of access has been used as part of ransomware operations against organizations relying on VSA for centralized endpoint administration.

How to fix it

Upgrade Kaseya VSA server and agents to version 9.5.7 or later, or the latest vendor-supported release. If immediate upgrade is not possible, remove internet exposure for VSA, restrict access to trusted administrative networks or VPN, disable or block unauthenticated access to /dl.asp where operationally feasible, and apply vendor-provided hardening guidance. Rotate VSA-related agent credentials and administrative credentials after patching, because credentials exposed before remediation may remain usable. Review and invalidate active sessions, especially sessionId cookies associated with suspicious /dl.asp activity. Because this vulnerability is known exploited and associated with ransomware activity, organizations with prior exposure should perform compromise assessment rather than relying on patching alone.

How to confirm the fix worked

Confirm the VSA server reports version 9.5.7 or later, or a later vendor-supported fixed release. Verify /dl.asp is no longer reachable unauthenticated from untrusted networks, or that exposed access is explicitly required and properly controlled. Test that submitting agent credentials through /dl.asp query parameters does not return a reusable privileged sessionId cookie. Review web server and application logs for historical requests to /dl.asp containing un= and pw= query parameters. Confirm that agent packages no longer disclose reusable credential material in a way that can be abused for broader VSA access. Validate network controls by testing from an external vantage point that only approved sources can reach the VSA web interface.

Typical attack path

1. Scan for internet-exposed Kaseya VSA servers or portals exposing /dl.asp.
2. Access the unauthenticated agent download page.
3. Download the Windows agent installer or related deployment package.
4. Install or unpack the agent package to obtain KaseyaD.ini.
5. Extract Agent_Guid and AgentPassword from KaseyaD.ini.
6. Submit the extracted values to /dl.asp using un= and pw= query parameters.
7. Capture the returned sessionId cookie.
8. Reuse the session cookie to access additional VSA functionality not intended for agent authentication.
9. Leverage VSA’s administrative reach to stage payloads, issue commands, move laterally, or deploy ransomware to managed endpoints.

How to detect it

Review web server, reverse proxy, WAF, and Kaseya VSA application logs for access to /dl.asp, especially requests containing un= and pw= query parameters and responses that set a sessionId cookie. Look for downloads of Windows agent packages from unusual external IP addresses, followed by authenticated requests using newly issued session cookies. Search for evidence that KaseyaD.ini files were accessed, copied, staged, or exfiltrated from systems where the agent was installed. Correlate suspicious /dl.asp activity with VSA audit events such as administrator logins, agent procedure creation or modification, software deployment tasks, script execution, credential changes, and unexpected package distribution. Because this vulnerability has been associated with ransomware activity, also examine managed endpoints for mass file encryption, unusual remote execution, PowerShell or cmd activity launched through the VSA agent, suspicious payload staging in temporary directories, and simultaneous task execution across many agents. Network telemetry should be reviewed for external access to VSA endpoints, anomalous session reuse, and unusual outbound connections from the VSA server after suspicious authentication events.

• /dl.asp?un=
• &pw=
• dl.asp?un=
• dl.asp?un=*pw=
• Set-Cookie: sessionId=
• Cookie: sessionId=
• KaseyaD.ini
• C:\Program Files (x86)\Kaseya\
• Agent_Guid
• AgentPassword
• GET /dl.asp
• POST /dl.asp
• /dl.asp

What your security team should do

• Treat any internet-exposed affected Kaseya VSA instance as high priority due to known exploitation, ransomware association, KEV listing, and high EPSS likelihood.
• Upgrade VSA server and agents to 9.5.7 or later, preferably the latest supported release, and verify the installed version after maintenance.
• Immediately restrict VSA web access to trusted administrative networks or VPN; do not expose /dl.asp or the VSA console directly to the internet unless absolutely required.
• Rotate VSA administrative credentials, agent-related credentials, API keys, and service account passwords after patching.
• Invalidate active sessions and review session issuance around suspicious /dl.asp activity.
• Search historical web logs for /dl.asp requests with un= and pw= parameters and correlate with new sessionId cookies, unusual source IPs, and subsequent administrative actions.
• Perform endpoint hunting across systems managed by VSA for ransomware staging, suspicious script execution, remote command execution, and unexpected software deployment jobs.
• Review VSA audit logs for unauthorized package distribution, script execution, agent procedure changes, credential access, and newly created or modified administrator accounts.
• If exploitation is suspected, isolate the VSA server, preserve logs and forensic images, and initiate incident response before restoring normal management operations.
• Track vendor advisories and CISA KEV guidance; the KEV remediation deadline was 2021-11-17, so any remaining unpatched instance is materially overdue.