Bishop Fox has published end-to-end confirmation of a two-vulnerability chain in Veeam Service Provider Console (VSPC) that results in unauthenticated remote code execution on the management server — the single server that sits above every tenant's backup infrastructure in a service-provider deployment. The researchers' own framing is the lesson: a GUID is not a credential. The console treated an unguessable identifier as proof of identity, and chained with a second flaw, that assumption collapses into full code execution.
For managed service providers and cloud service providers, this is close to a worst-case scenario. The VSPC server holds the keys to tenant backup jobs, agents, and restore points across the entire customer base. An attacker who executes code on this host doesn't get one tenant's data — they get a launchpad into every tenant's environment, plus the ability to delete or encrypt backups before a ransomware wave. Backup management infrastructure has been a priority target for years precisely because of this blast radius, and unauthenticated pre-auth RCE on that tier demands immediate action.
Technical Analysis
Affected Product
- Product: Veeam Service Provider Console (VSPC) — the multi-tenant management platform used by service providers to manage Veeam Backup & Replication tenants, cloud connect, and backup agents
- Component: The VSPC web/API layer running on the management server (Windows Server, IIS-hosted application)
- Exposure: Any VSPC management interface reachable from untrusted networks — and Bishop Fox's research shows authentication is not a barrier even if you believed the portal was "protected by login"
Root Cause: Two Flaws, One Chain
Based on Bishop Fox's disclosure, the chain breaks down into two distinct root causes:
-
Broken authentication via GUID-based identity. The application treated a GUID — an identifier that is hard to guess but not a secret issued after authentication — as sufficient proof of identity. This is a classic CWE-639 (Authorization Bypass Through User-Controlled Key) / insecure direct object reference pattern: knowing or obtaining the identifier grants the access. GUIDs leak through logs, error messages, referrer headers, other API responses, and tenant-side artifacts. Unguessability is not authentication.
-
A second critical flaw that converts that access into code execution. Once past the authentication assumption, the attacker reaches functionality that yields command execution on the management server itself — the highest-value host in the provider's backup estate.
Bishop Fox confirmed the full chain end to end against a live target and, importantly for defenders, released a safe detection tool and IOCs alongside the write-up.
Exploitation Status
- Confirmed working exploit chain: Yes — demonstrated end to end by Bishop Fox
- Public technical details and detection tooling: Published (Bishop Fox blog, including IOCs and a safe checker)
- In-the-wild exploitation: Not publicly confirmed at time of writing — but the publication of a fully documented, unauthenticated RCE chain against backup management infrastructure historically compresses the time-to-exploitation window to days or weeks. Treat this as imminent, not theoretical.
Why the Target Matters
VSPC is not a line-of-business app. It orchestrates backup agents on tenant endpoints, manages cloud repositories, and stores credentials and configuration for downstream infrastructure. Code execution here means:
- Mass deployment of malware through the backup agent channel (a supply-chain-style push to every tenant)
- Destruction or encryption of tenant backups ahead of a ransomware event
- Theft of stored credentials and tenant configuration data
- Persistence in a tier that most tenant-side EDR never sees
Detection & Response
The most reliable post-exploitation signal for web-tier RCE on a Windows-hosted management console is the web application process doing things it has no legitimate reason to do: spawning shells, scripting interpreters, or reconnaissance binaries; writing executable content to web-accessible directories; or initiating unexpected outbound connections. The detections below target exactly that behavior on the VSPC host.
---
title: Veeam Service Provider Console Web Process Spawning Shell or Script Interpreter
id: 3f8a2c91-7d54-4b6e-9a21-c5e8f0a1b2c3
status: experimental
description: Detects the VSPC web application process (IIS worker or Veeam service process) spawning command shells, PowerShell, or other LOLBins, consistent with post-exploitation of the unauthenticated RCE chain disclosed by Bishop Fox.
references:
- https://bishopfox.com/blog/a-guid-is-not-a-credential-unauthenticated-rce-in-veeam-service-provider-console
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059
- attack.initial_access
- attack.t1190
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\w3wp.exe'
- '\Veeam.Manager.Agent.exe'
- '\Veeam.VSPortal.exe'
- '\dotnet.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\cscript.exe'
- '\wscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\whoami.exe'
- '\net.exe'
- '\nltest.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare; legitimate VSPC management actions do not typically invoke interactive shells from the web worker process. Validate against documented maintenance activity.
level: high
---
title: Executable or Script File Created in Veeam Service Provider Console Web Directories
id: 8b1d4e62-3a97-4f5c-b2d8-9e0a6c3f7d41
status: experimental
description: Detects creation of scripts or executables in VSPC web root and application directories, indicating possible web shell deployment following exploitation of the unauthenticated RCE chain.
references:
- https://bishopfox.com/blog/a-guid-is-not-a-credential-unauthenticated-rce-in-veeam-service-provider-console
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1505.003
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\Veeam\Backup and Replication Console\'
- '\Veeam\Service Provider Console\'
- '\inetpub\'
- '\VeeamVAC\'
selection_ext:
TargetFilename|endswith:
- '.aspx'
- '.ashx'
- '.asmx'
- '.php'
- '.jsp'
- '.exe'
- '.dll'
- '.ps1'
- '.bat'
- '.hta'
condition: selection_path and selection_ext
falsepositives:
- Veeam product updates and hotfix installations. Correlate with patch windows and installer processes (msiexec.exe, Veeam setup binaries).
level: high
---
title: Suspicious Outbound Connection from VSPC Web Application Process
id: c27e5f08-6b43-4d1a-a8f2-3d9c1e5b7046
status: experimental
description: Detects the VSPC web/worker process initiating outbound connections to non-standard destinations, consistent with C2 establishment after unauthenticated code execution.
references:
- https://bishopfox.com/blog/a-guid-is-not-a-credential-unauthenticated-rce-in-veeam-service-provider-console
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.command_and_control
- attack.t1071.001
logsource:
category: network_connection
product: windows
detection:
selection_image:
Image|endswith:
- '\w3wp.exe'
- '\Veeam.Manager.Agent.exe'
filter_known:
DestinationIp|startswith:
- '10.'
- '172.16.'
- '192.168.'
- '169.254.'
- '127.'
condition: selection_image and not filter_known
falsepositives:
- Cloud repository traffic to object storage endpoints and Veeam update/telemetry servers. Baseline per environment and allowlist documented cloud endpoints.
level: medium
// Hunt: VSPC host web/worker processes spawning shells or LOLBins (potential RCE post-exploitation)
// Scope to your VSPC management servers. Requires MDE or equivalent process telemetry.
let VSPCParents = dynamic(["w3wp.exe", "Veeam.Manager.Agent.exe", "dotnet.exe"]);
let LOLBins = dynamic(["cmd.exe","powershell.exe","pwsh.exe","cscript.exe","wscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","certutil.exe","bitsadmin.exe","whoami.exe","net.exe","nltest.exe","curl.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (VSPCParents)
| where FileName in~ (LOLBins)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, AccountName, ReportId
| order by TimeGenerated desc;
// Corroborate with inbound requests to the VSPC web interface (default TCP 1280) from unusual sources
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DestinationPort == 1280
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, DestinationHostName, RequestURL
| order by RequestCount desc;
-- Hunt VSPC host for web-tier post-exploitation artifacts:
-- 1) recently created scripts/executables under Veeam and IIS directories (potential web shells)
-- 2) web/worker processes with suspicious child commands
LET recent_files <= SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
'C:/Program Files/Veeam/**/*.aspx',
'C:/Program Files/Veeam/**/*.ashx',
'C:/Program Files/Veeam/**/*.ps1',
'C:/inetpub/**/*.aspx',
'C:/inetpub/**/*.ashx',
'C:/inetpub/**/*.exe'
])
WHERE Mtime > now() - 1209600
SELECT FullPath, Size, Mtime FROM recent_files ORDER BY Mtime DESC
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(powershell|cmd\.exe|certutil|bitsadmin|mshta|rundll32|whoami|nltest)'
AND (Name =~ '(?i)(w3wp|Veeam)' OR CommandLine =~ '(?i)Veeam')
# VSPC exposure verification and hardening script — run elevated on the VSPC management server
# 1) Identify installed VSPC version for patch validation against the current Veeam advisory
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*,
HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -match 'Veeam' } |
Select-Object DisplayName, DisplayVersion, InstallDate | Format-Table -AutoSize
# 2) Verify the VSPC web interface (default TCP 1280) is NOT exposed to untrusted networks
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallRule -Direction Inbound -Action Allow |
Where-Object { $_.Enabled -eq 'True' } |
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq '1280' } | Format-Table
# 3) Restrict the management portal to an administrative allowlist (adjust -RemoteAddress)
New-NetFirewallRule -DisplayName "VSPC Portal - Admin Allowlist Only" `
-Direction Inbound -Protocol TCP -LocalPort 1280 -Action Allow `
-RemoteAddress "10.0.10.0/24" -Profile Any
New-NetFirewallRule -DisplayName "VSPC Portal - Block All Else" `
-Direction Inbound -Protocol TCP -LocalPort 1280 -Action Block -Profile Any
# 4) Audit for suspicious child processes of the web/worker process in the last 14 days
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-14)} -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'w3wp.exe|Veeam.Manager.Agent.exe' -and
$_.Message -match 'cmd.exe|powershell.exe|mshta.exe|certutil.exe|rundll32.exe' } |
Select-Object TimeCreated, Message | Format-List
Remediation
-
Patch immediately. Apply the current Veeam security update addressing this issue as published in Veeam's security advisories: https://www.veeam.com/knowledge-base.html?type=security. Review the Bishop Fox disclosure for the specific fixed build and validate your installed version against it using the script above. Do not rely on "the portal requires login" as mitigation — the entire point of this chain is that it does not.
-
Run Bishop Fox's safe detection tool. The researchers released a non-exploitative checker along with IOCs. Run it against every VSPC server you operate, and ingest the published IOCs into your EDR and SIEM.
-
Isolate the management plane. The VSPC web interface should never be reachable from the internet or from general tenant networks. Restrict it to a provider-side administrative network via firewall policy and, ideally, behind a VPN or zero-trust gateway. If your portal is currently internet-exposed, treat that as an incident, not a configuration issue.
-
Hunt before you assume clean. Apply the Sigma, KQL, and VQL content above across at least the last 30 days of telemetry on the VSPC host. Look specifically for web-shell files under Veeam/IIS directories and for shells spawned by the web worker process.
-
Rotate credentials stored in VSPC. If any evidence of compromise exists, assume stored tenant credentials, cloud repository keys, and agent configuration secrets are exposed. Rotate them in priority order: domain/privileged accounts first, then cloud storage keys, then tenant agent credentials.
-
Design lesson for your own estate. Inventory any internal application that uses "unguessable" identifiers (GUIDs, tokens in URLs) as an authorization boundary. That pattern — the exact root cause here — is pervasive. Require server-side session validation on every request; an identifier is a locator, not a credential.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.