Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -561,6 +561,7 @@
- [Tomcat](network-services-pentesting/pentesting-web/tomcat/README.md)
- [Telerik Ui Aspnet Ajax Unsafe Reflection Webresource Axd](network-services-pentesting/pentesting-web/telerik-ui-aspnet-ajax-unsafe-reflection-webresource-axd.md)
- [Uncovering CloudFlare](network-services-pentesting/pentesting-web/uncovering-cloudflare.md)
- [Veeam Service Provider Console](network-services-pentesting/pentesting-web/veeam-service-provider-console.md)
- [Vuejs](network-services-pentesting/pentesting-web/vuejs.md)
- [VMWare (ESX, VCenter...)](network-services-pentesting/pentesting-web/vmware-esx-vcenter....md)
- [Web API Pentesting](network-services-pentesting/pentesting-web/web-api-pentesting.md)
Expand Down
1 change: 1 addition & 0 deletions src/network-services-pentesting/pentesting-web/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -104,6 +104,7 @@ Some **tricks** for **finding vulnerabilities** in different well known **techno
- [**Spring Actuators**](spring-actuators.md)
- [**Symphony**](symphony.md)
- [**Tomcat**](tomcat/index.html)
- [**Veeam Service Provider Console**](veeam-service-provider-console.md)
- [**VMWare**](vmware-esx-vcenter....md)
- [**Web API Pentesting**](web-api-pentesting.md)
- [**WebDav**](put-method-webdav.md)
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
# Veeam Service Provider Console (VSPC)

{{#include ../../banners/hacktricks-training.md}}

## Attack surface

VSPC is a Windows backup-management control plane with a web portal and a proprietary management-agent channel. Agents normally reach `ConnectionHub` directly on **TCP/9999**; Veeam Cloud Connect can expose the same channel through a relay on **TCP/6180**. The hub parses a small framing handshake, selects a receiver by name, and tunnels the connection to the Application Server, where TLS and agent authorization occur.<sup>[[1]](#references)</sup>

Treat VSPC as both a web application and an agent/RPC service. Useful initial checks are:<sup>[[1]](#references)</sup>

- Locate the web console on TCP/80 or TCP/443 and record its displayed build.
- Test TCP/9999 from management and tenant networks, not only from the Internet.
- Where Cloud Connect is deployed, test TCP/6180 because the gateway may relay the agent protocol unchanged.
- Capture both the outer `ConnectionHub` handshake and the tunneled TLS exchange; authentication does not happen at the first protocol parser.

## Global-session identity confusion

The VSPC agent certificate encodes identifiers rather than a conventional username:<sup>[[1]](#references)</sup>

```text
CN = <agentId GUID>
O = "<companyId GUID>[;<clusteredAgentId GUID>]"
OU = <locationId GUID>
```

In affected VSPC 9 builds, authorization asked whether the attacker-supplied `clusteredAgentId` existed in a process-global login dictionary. It did **not** verify that the matching login belonged to the certificate, TLS connection, or socket making the current request. A peer claiming an active agent's GUID could therefore inherit the authorization state of that other connection.<sup>[[1]](#references)</sup>

This became exploitable because strong certificate authorization was disabled by default. A self-signed certificate that failed chain validation could still complete the enrollment path as a guest; the later GUID-only lookup then found the real agent's login. When that lookup passed, VSPC installed neither the anonymous nor the secondary-agent RPC interceptor, leaving unrestricted default method invocation.<sup>[[1]](#references)</sup>

This is a useful review pattern for RMM, MDM, backup, and IoT control planes: test whether attacker-controlled device or tenant IDs are looked up in shared login state after a permissive enrollment handshake. An identifier is not proof that the current channel owns the corresponding session; bind the lookup to a validated certificate thumbprint, channel-bound token, or fresh cryptographic proof.<sup>[[1]](#references)</sup>

### Finding a connected agent identifier

The GUID is not realistically brute-forceable, but it is not a credential. The demonstrated collection opportunities were:<sup>[[1]](#references)</sup>

- **TLS 1.2 capture:** the client `Certificate` message precedes `ChangeCipherSpec`, exposing the certificate subject and its GUIDs to an on-path observer.
- **Managed Windows endpoint:** ordinary `BUILTIN\Users` members could read `HKLM\SOFTWARE\Veeam\VAC\Agent\AgentId`, agent logs, or the installed agent certificate.
- **Existing console/API access:** an operator or compromised portal session can obtain the enrolled agent identifiers.

A valid candidate must normally correspond to an agent that is connected at that moment, because only a successful certificate-validating login populates the vulnerable global login table.<sup>[[1]](#references)</sup>

### Converting transient impersonation into a credential

Once the interceptor was skipped, `IServerCertificateDispatcher.IssueCertificateForAgent` returned a password-protected PKCS#12 bundle, its password, a private key, and an agent certificate signed by the console's agent root CA. Reconnecting with this genuine certificate removed the dependency on the victim agent remaining online and converted session confusion into a durable authenticated foothold.<sup>[[1]](#references)</sup>

When auditing a similar agent protocol, enumerate certificate-issuance, key-rotation, bootstrap-token, and device-recovery RPCs immediately after any temporary authorization bypass. Also verify revocation: upgrading VSPC fixes issuance but does not automatically invalidate agent certificates issued before the upgrade.<sup>[[1]](#references)</sup>

## Authenticated arbitrary file write

The agent-facing `SaveFiles` RPC combined a fixed share with an attacker-controlled subfolder and later combined that result with an attacker-controlled filename. The relevant pattern was:<sup>[[1]](#references)</sup>

```csharp
var target = Path.Combine(shareRoot, package.DefinedPathSubfolder);
var file = Path.Combine(target, item.FileName);
Directory.CreateDirectory(target);
new FileStream(file, FileMode.Create, FileAccess.ReadWrite);
```

A rooted Windows value such as `C:\inetpub\wwwroot` in the second `Path.Combine` argument discards the intended share root. This produces an arbitrary file-write primitive without `..\` sequences, so traversal-only signatures miss it. `Directory.CreateDirectory` creates a missing destination, and `FileMode.Create` creates or truncates the chosen file with the VSPC service account's privileges.<sup>[[1]](#references)[[4]](#references)</sup>

See [Archive Extraction Path Traversal](../../generic-hacking/archive-extraction-path-traversal.md) for the same rooted-path override and containment-check pattern in .NET. If the destination is an active IIS web root, writing an executable server-side page and requesting it yields execution as the application-pool identity; continue with the [IIS writable-webroot methodology](iis-internet-information-services.md).<sup>[[1]](#references)[[4]](#references)</sup>

The VSPC chain was therefore:<sup>[[1]](#references)</sup>

1. Reach TCP/9999 or the TCP/6180 relay.
2. Obtain the subject identifiers of a connected agent.
3. Present a self-signed certificate containing those identifiers.
4. Abuse the unbound global login lookup to obtain unrestricted RPC invocation.
5. Request a genuine agent PKCS#12 credential.
6. Reconnect with that credential and call `SaveFiles` with a rooted destination.
7. Write into an executable or configuration sink such as the IIS web root.

## Safe patch-state fingerprinting

Bishop Fox's [CVE-2026-58073-check](https://github.com/BishopFox/CVE-2026-58073-check) scanner fingerprints a pre-authentication protocol change without presenting a certificate, registering a receiver, requesting credentials, or writing a file. It first advertises protocol version 6 and requires VSPC's receiver-not-found response; only after this product gate succeeds does it advertise version 7.<sup>[[3]](#references)</sup>

| Result | Version 6 | Version 7 |
| --- | --- | --- |
| Missing KB4893 fixes | `Requested receiver not found` | socket closes with zero response bytes |
| KB4893 fixes present | `Requested receiver not found` | parsed receiver-not-found XML response |
| Not VSPC / filtered | fingerprint gate fails | no vulnerable verdict |

This two-stage design prevents an unrelated quiet service or firewall from being classified as vulnerable merely because the version-7 probe returned no data.<sup>[[3]](#references)</sup>

```bash
git clone https://github.com/BishopFox/CVE-2026-58073-check
cd CVE-2026-58073-check

# Direct ConnectionHub; TCP/9999 is the default
python3 cve_2026_58073_check.py vspc.example.com --brief

# Cloud Connect relay transport is auto-detected on TCP/6180
python3 cve_2026_58073_check.py cc-gw.example.com:6180 --brief

# Scan a list and preserve structured evidence
python3 cve_2026_58073_check.py -f targets.txt --json > results.json
```

A normal direct scan makes two TCP connections and leaves receiver names beginning with `bf-probe-` in `%ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log`. The result identifies the protocol generation, not an exact build or evidence of historical exploitation.<sup>[[3]](#references)</sup>

## Log-based detection

VSPC logs live below `%ProgramData%\Veeam\Veeam Availability Console\Log\`. On patched servers, an attempt to call the deleted file-write method produces the deliberately useful misspelled token below; search `Suspicio` to cover both spellings and anchor the event on `ServerEndpointDownloadAcceptor`.<sup>[[1]](#references)</sup>

```text
Suspicios call from channel Id: <channel-guid>
Path '<path>' is outside of the allowed service folders. Suspicious call from channel Id: <channel-guid>
```

The first line is the high-confidence deleted-`SaveFiles` guard. The second can also arise when a remaining write method targets a path outside its allowlist. Deduplicate error events because they may also be copied into `Server_error.log`, and correlate the channel GUID with `Incoming method call 'SaveFiles'` in `Agent_Communication.log`.<sup>[[1]](#references)</sup>

Unpatched builds have no path guard, but `FromVmbpDownloader` logs the full destination. Alert when `Saving file <full path>` points outside expected VSPC shares, especially to `C:\inetpub\wwwroot`, a service-binary directory, or another executable/configuration location.<sup>[[1]](#references)</sup>

For agent impersonation, correlate the same agent GUID and replacement channel across `AgentAuthorization.log` and `Agent_Communication.log`. The distinctive sequence is:<sup>[[1]](#references)</sup>

```text
certificate <thumbprint> did not pass validation.
Channel <old> used by agent <guid> is being replaced with channel <new>
Incoming method call 'IssueCertificateForAgent'
Channel <new> released for agent <guid>
```

Prefer this ordered correlation over reconnect-rate alerts: legitimate agents replace channels during routine operation, while certificate-validation failure followed within seconds by channel replacement and certificate issuance is the important discriminator. A subsequent unexpected `Saving file` event indicates the complete chain.<sup>[[1]](#references)</sup>

## Patch and containment

Veeam states that VSPC **9.2.1.33875 and all earlier version 9 builds** are affected and that the fixed release is **9.3.0.35057**. Remediation requires upgrading rather than installing a 9.2.x hotfix.<sup>[[2]](#references)</sup>

Restrict TCP/9999 to management-agent networks and assess every exposed Cloud Connect path on TCP/6180. If the logs indicate certificate issuance to an impersonated agent, do not treat the software upgrade as credential revocation: temporarily rejecting the affected agent reduces a stolen certificate to the anonymous RPC surface, but certificate-remediation guidance should be obtained from Veeam Support.<sup>[[1]](#references)</sup>

## References

- [1] [Bishop Fox - A GUID Is Not a Credential: Unauthenticated RCE in Veeam Service Provider Console](https://bishopfox.com/blog/a-guid-is-not-a-credential-unauthenticated-rce-in-veeam-service-provider-console)
- [2] [Veeam KB4893 - Veeam Service Provider Console Security Vulnerabilities](https://www.veeam.com/kb4893)
- [3] [Bishop Fox - CVE-2026-58073-check](https://github.com/BishopFox/CVE-2026-58073-check)
- [4] [Microsoft Learn - Path.Combine Method](https://learn.microsoft.com/en-us/dotnet/api/system.io.path.combine)

{{#include ../../banners/hacktricks-training.md}}