Skip to content

CVE-2026-44963: Remote Code Execution in Veeam Backup & Replication via .NET Remoting ObjRef Deserialization

HERMES

HERMES THREAT SCORE & ENTERPRISE RISK

Target: Veeam Backup & Replication - VeeamThreatHunterSvc (.NET Remoting TCP 6175)
Confidence: 99%
96 / 100
CRITICAL

Measures real-world operational relevance, exploit weaponization, and active threat posture.

Dimension Breakdown
Exploitability 19 / 20
Threat Activity 18 / 20
Weaponization 19 / 20
Exposure 18 / 20
Prevalence 19 / 20
Impact 20 / 20
Exploit Maturity 18 / 20
Attack Chain Potential 20 / 20
⚖️ Divergence & Operational Rationale

CVSS v3.1 rates CVE-2026-44963 at 9.8 (Critical) while CVSS v4.0 evaluates it at 9.3. Hermes Threat Score assesses it at 96 (CRITICAL). In an enterprise Windows Active Directory environment, the vulnerability converts any compromised low-privileged domain user into unconstrained NT AUTHORITY\SYSTEM code execution on the organization's backup server. Compromising the backup recovery plane is historically the final prerequisite for catastrophic enterprise ransomware deployment (e.g., Akira, Qilin, Fog, LockBit).

🕸️ Connected Knowledge Graph & Provenance

CVE-2026-44963: Remote Code Execution in Veeam Backup & Replication via .NET Remoting ObjRef DeserializationVULNERABILITY

Connected Nodes: 1
Active Relationships (Outgoing)
→ affectsPRODUCTVeeam Backup & Replication
98% VERY_HIGH

Software platform affected by security vulnerabilities and agentic attack patterns.

🔍 Why is this related? (Evidence & Provenance)

“Confirmed security vulnerability in Veeam Backup & Replication documented in Hermes dossier.”

Supporting Verified Evidence:

1. Vulnerability Metadata & Affected Surface

Section titled “1. Vulnerability Metadata & Affected Surface”

The following matrix provides an exhaustive scope analysis across affected software builds, architectural components, and authentication boundary assumptions.

ParameterTechnical SpecificationOperational Impact
CVE IdentifierCVE-2026-44963Global tracking identifier
Vendor AdvisoryVeeam KB4869Hotfix and release bundle
Vulnerable DaemonVeeamThreatHunterSvc.exeVeeam Backup Threat Hunter Service
Transport LayerRaw TCP on port 6175/TCPCustom binary .NET Remoting channel
Vulnerable Pipeline.NET Remoting Deserialization SinkWhitelist filter bypassed via ObjRef proxy invocation
Execution PrivilegesNT AUTHORITY\SYSTEMAbsolute host compromise
Affected BuildsVBR 12.0 (Build 12.0.0.1420) through 12.3.2.4465Default deployment on domain-joined hosts
Patched BuildVBR 12.3.2.4854 (KB4869)Binary patch modifying remoting validation
Immune ArchitectureVBR v13 (Build 13.0.1.2067 and newer)Modernized to .NET 8 / Kestrel; Remoting completely deleted
Domain PreconditionHost joined to an Active Directory domainBUILTIN\Users includes NT AUTHORITY\Authenticated Users

The Authentication Fallacy: Why It Is Functionally Unauthenticated

Section titled “The Authentication Fallacy: Why It Is Functionally Unauthenticated”

While Veeam’s advisory notes that the attacker must possess network connectivity and domain credentials, in modern enterprise architectures, this vulnerability must be treated as effectively unauthenticated RCE for the following reasons:

  1. Active Directory Token Expansion: The service’s authorization routine verifies new WindowsPrincipal(windowsIdentity).IsInRole(WindowsBuiltInRole.User). On any Windows server joined to an Active Directory domain, the local group BUILTIN\Users automatically and recursively includes the Active Directory principal NT AUTHORITY\Authenticated Users.
  2. Ubiquitous Domain Footholds: Any domain account—regardless of how restricted (e.g., machine accounts, unprivileged contractor accounts, guest accounts without tier segregation)—passes this check immediately over NTLM or Kerberos negotiation on port 6175.
  3. Machine Account Abuse: Attackers who compromise any low-tier workstation or IoT device joined to the domain can utilize its computer account (DOMAIN\WORKSTATION$) to negotiate NTLM, satisfying the authorization gate with zero human credential theft.

As highlighted in Penligent’s technical research, backup infrastructure cannot be evaluated as an ordinary application server. A backup platform is a privileged recovery control plane:

  • It maintains administrative credentials to hypervisors (VMware vCenter, ESXi, Hyper-V, Nutanix).
  • It stores cataloged metadata and decryption keys for the organization’s entire data estate.
  • It interfaces with storage arrays, cloud object storage repositories, and tape libraries.

Historically, ransomware syndicates (including Akira, Fog, Frag, and LockBit) deliberately hunt for Veeam Backup & Replication infrastructure. Gaining NT AUTHORITY\SYSTEM access allows attackers to purge restore points, encrypt backup repositories, exfiltrate virtual disk snapshots, and eliminate recovery options prior to deploying ransomware network-wide.


To understand how a defense-in-depth allowlist of 4,200 types was circumvented, one must analyze the inner workings of legacy .NET Remoting, custom transport sinks, and the dual-legged nature of RPC request-response deserialization.

+-----------------------------------------------------------------------------------------+
| CVE-2026-44963 DUAL-LEG EXPLOIT MECHANICS |
+-----------------------------------------------------------------------------------------+
[Attacker Machine] [Veeam Backup Server]
IP: 192.168.1.100 IP: 192.168.1.10
Port: TCP 6175 (VeeamThreatHunterSvc)
│ │
[1] │───── TCP Connect & NTLM Auth (Any Domain Account) ───────────>│ (Passes IsInRole: BUILTIN\Users)
│ │
[2] │───── Serialized Remoting Packet with ObjRef ─────────────────>│ Deserializes ObjRef (In Whitelist!)
│ (Points to tcp://192.168.1.100:9999/pwn) │ Instantiates TransparentProxy
│ │
│ │ Service executes:
│ │ EnsureAccessIsAllowed()
│ │ Reads msg.MethodBase property
│ │
[3] │<════ Outbound TCP Callback to Attacker:9999 ══════════════════│ TransparentProxy triggers RPC
│ "Get property MethodBase on remote object" │
│ │
[4] │═════ Malicious Reply Leg: SortedSet + TypeConfuseDelegate ═══>│ _serializingResponse == true:
│ Gadget executes: Process.Start("cmd.exe", ...) │ Custom Whitelist Bypassed!
│ │
│ │ [!] NT AUTHORITY\SYSTEM Shell

The network entrypoint of VeeamThreatHunterSvc.exe binds to 0.0.0.0:6175 via a TcpServerChannel. Upon receiving an incoming remoting request, the service inspects the client’s authenticated Windows identity:

// Decompiled from Veeam.Backup.ThreatHunter.Service.dll
private bool ValidateClientIdentity(IIdentity identity)
{
WindowsIdentity windowsIdentity = identity as WindowsIdentity;
if (windowsIdentity == null)
return false;
WindowsPrincipal principal = new WindowsPrincipal(windowsIdentity);
// VULNERABILITY: Checks local BUILTIN\Users role
if (principal.IsInRole(WindowsBuiltInRole.User))
{
return true;
}
return false;
}

Because domain membership injects DOMAIN\Domain Users into BUILTIN\Users, this gate fails to establish an isolation boundary. Every authenticated entity in the Active Directory forest is granted authorization to invoke the service’s remoting sinks.

In response to historical deserialization vulnerabilities (such as CVE-2024-40711 and CVE-2023-38548), Veeam engineers implemented a custom remoting channel sink provider that enforced an allowlist of approved types loaded from a file named whitelist.txt. This list contained approximately 4,200 classes permitted to be deserialized by the BinaryFormatter.

Standard gadget chains (e.g., TypeConfuseDelegate, ObjectDataProvider, FileSystemUtils) were absent from whitelist.txt and were blocked by the sink. However, the allowlist explicitly included:

System.Runtime.Remoting.ObjRef

In .NET Remoting, an ObjRef is an architectural object storing all the metadata required to generate a remote proxy for an object living in another application domain or across the network. When BinaryFormatter deserializes an ObjRef, it automatically creates a System.Runtime.Remoting.Proxies.TransparentProxy acting on behalf of the specified URI.

Furthermore, by sending raw binary frames directly into the remoting transport sink rather than through standard high-level client stubs, the attacker bypasses .NET’s TypeFilterLevel.Low restrictions because .NET marks the internal remoting context flag IsRemoting = false during direct stream ingestion.

Flaw 3: The Reverse Trigger (“Asking the Attacker for Permission”)

Section titled “Flaw 3: The Reverse Trigger (“Asking the Attacker for Permission”)”

Once the deserialization sink finishes reconstructing the message parameters, the Veeam service executes its internal access validation check: EnsureAccessIsAllowed(...).

// Simplified representation of Veeam access control routine
public void EnsureAccessIsAllowed(IMethodCallMessage msg)
{
// The server reads the method name or target interface metadata
MethodBase method = msg.MethodBase;
string methodName = method.Name;
// Check against authorized operation contracts...
}

Here lies the fatal architectural flaw: the object within msg is not a local object—it is the deserialized TransparentProxy pointing to tcp://attacker-ip:9999/remote-object.

When the Veeam server code reads msg.MethodBase, the .NET Remoting CLR infrastructure intercepts the property getter. Because it is a proxy, the runtime pauses execution and dispatches an outbound TCP remoting call back to the attacker’s server to retrieve the requested metadata!

When the attacker’s listener receives the incoming TCP connection from the Veeam server, it responds to the property query.

Inside Veeam’s custom security sink, the filtering logic is gated by an internal state flag:

if (!_serializingResponse)
{
// Apply strict whitelist validation on incoming requests
EnforceTypeWhitelist(deserializedObject);
}
else
{
// Responses are assumed to originate from trusted internal components
PassThrough();
}

Because the Veeam server is acting as the client in this outbound transaction, the incoming packet from the attacker is categorized as a response/reply leg. The allowlist validation is completely skipped!

The attacker transmits a classic, uninhibited .NET deserialization gadget chain:

  1. SortedSet<string> combined with a custom IComparer
  2. ComparisonComparer<string> wrapping a MulticastDelegate
  3. TypeConfuseDelegate linking to System.Diagnostics.Process.Start("cmd.exe", "/c ...")

As soon as the Veeam server deserializes the response stream, Process.Start is invoked within the context of VeeamThreatHunterSvc.exe, spawning the attacker’s process with full NT AUTHORITY\SYSTEM integrity.


  1. Network discovery & target profiling: The adversary discovers an accessible Veeam Backup & Replication server listening on TCP port 6175.
  2. NTLM / Kerberos handshake: The attacker initiates a .NET Remoting TCP channel connection, presenting valid NTLM credentials for any low-privileged domain user or compromised machine account (WORKSTATION$).
  3. Payload construction & injection: The attacker crafts a binary remoting request containing an allowlisted System.Runtime.Remoting.ObjRef pointing to an attacker-controlled listener at tcp://192.168.1.100:9999/Service.
  4. Proxy instantiation & outbound callback: VeeamThreatHunterSvc.exe deserializes the ObjRef, producing a TransparentProxy. The server enters EnsureAccessIsAllowed and queries msg.MethodBase. The CLR automatically opens an outbound TCP connection to the attacker’s listener at 192.168.1.100:9999.
  5. Malicious reply leg delivery: The attacker’s listener captures the connection and returns a serialized SortedSet<string> gadget containing TypeConfuseDelegate configured to invoke arbitrary operating system commands.
  6. Code execution as SYSTEM: The Veeam server deserializes the reply without allowlist validation. Process.Start executes, yielding an interactive shell or dropping a persistent implant with NT AUTHORITY\SYSTEM privileges.

4. Asset Discovery & Exposure Management (runZero Research)

Section titled “4. Asset Discovery & Exposure Management (runZero Research)”

As documented in runZero’s exposure management research, security teams cannot protect what they cannot discover. In enterprise environments, secondary backup proxies, test instances, and decentralized Veeam deployments often sit unnoticed on general subnets.

To locate all deployed Veeam instances across the enterprise:

# Query 1: Discover all Veeam Backup & Replication instances
vendor:=Veeam AND (product:="Backup & Replication" OR product:="Veeam Backup & Replication")
# Query 2: Pinpoint specifically vulnerable versions (v12 prior to 12.3.2.4854)
vendor:=Veeam AND product:="Veeam Backup & Replication" AND (version:>0 AND version:>=12 AND version:<12.3.2.4854)

4.2 Network Service Discovery & Port Fingerprinting

Section titled “4.2 Network Service Discovery & Port Fingerprinting”

Defenders can detect unmanaged Veeam services using network-level service queries:

# Discover Veeam Service Provider Console (VSPC) web interfaces
has:"html.title" html.title:"Veeam Service Provider Console"
# Discover Veeam Distribution Service API listeners
tcp_port:9380
# Fingerprint Veeam Threat Hunter Remoting service
tcp_port:6175

5. Local PowerShell Audit & Technical Assessment Toolkit

Section titled “5. Local PowerShell Audit & Technical Assessment Toolkit”

To evaluate compliance on individual Windows servers without third-party agents, administrators can execute the following operational verification scripts (adapted from Penligent’s technical assessment methodology):

Terminal window
# 1. Identify installed Veeam products and exact build versions
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -like "*Veeam Backup*" } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
Format-Table -AutoSize
# 2. Check Active Directory domain membership status (Vulnerability Precondition)
(Get-CimInstance Win32_ComputerSystem) |
Select-Object Name, Domain, PartOfDomain |
Format-List
# 3. Check status of all Veeam-related Windows services
Get-Service |
Where-Object { $_.DisplayName -like "*Veeam*" -or $_.Name -like "*Veeam*" } |
Sort-Object Status, Name |
Select-Object Status, Name, DisplayName, StartType |
Format-Table -AutoSize

6. Indicators of Compromise (IOCs) & SOC Investigation Matrix

Section titled “6. Indicators of Compromise (IOCs) & SOC Investigation Matrix”

Forensic investigators responding to potential CVE-2026-44963 intrusions should evaluate network, host, and event telemetry across the following vectors.

6.1 Network Indicators (North-South & East-West)

Section titled “6.1 Network Indicators (North-South & East-West)”
[Suspicious Inbound Connection]
Source IP: Internal IP (workstation, DMZ bastion, or unmanaged endpoint)
Destination IP: Veeam Backup & Replication Server
Destination Port: 6175/TCP
Protocol: .NET Remoting (raw TCP channel with NTLM authentication header)
[Malicious Outbound Callback (The Reverse Trigger)]
Source IP: Veeam Backup & Replication Server
Source Port: Ephemeral high port (e.g., 49152 - 65535)
Destination IP: Untrusted internal IP or external IP
Destination Port: Arbitrary high port (e.g., 4444, 8888, 9999, 1337)
Payload Signature: Remoting handshake or binary stream containing System.Runtime.Remoting

6.2 Host & Process Telemetry (Parent-Child Anomalies)

Section titled “6.2 Host & Process Telemetry (Parent-Child Anomalies)”

Under normal operating conditions, VeeamThreatHunterSvc.exe executes backup catalog indexing, guest OS file indexing, and threat scanning tasks. It never spawns interactive command interpreters, scripting engines, or network utilities.

Parent Process: C:\Program Files\Veeam\Backup and Replication\Backup\VeeamThreatHunterSvc.exe
Parent User: NT AUTHORITY\SYSTEM
Suspicious Child Processes (CRITICAL ALERT):
- cmd.exe
- powershell.exe / pwsh.exe
- wscript.exe / cscript.exe
- mshta.exe
- certutil.exe
- curl.exe / bitsadmin.exe
- rundll32.exe / regsvr32.exe
- whoami.exe / net.exe / net1.exe / nltest.exe
  • Event ID 4624 (Successful Logon):
    • Logon Type: 3 (Network Logon)
    • Logon Process: NtLmSsp or Kerberos
    • Workstation Name: Identifier of attacker-controlled device
    • Target User Name: Any unprivileged domain account or machine account immediately preceding anomalous service activity.
  • Event ID 4688 (Process Creation):
    • Creator Process Name: *\VeeamThreatHunterSvc.exe
    • New Process Name: Command shell or script host.
    • Token Elevation Type: TokenElevationTypeDefault (1) running as S-1-5-18 (Local System).
  • Event ID 1000 / 1026 (.NET Runtime Crash / Exception):
    • If an exploit payload encounters a type mismatch or malformed remoting stream, the CLR logs an Application Error detailing System.Runtime.Remoting.RemotingException or System.Runtime.Serialization.SerializationException within VeeamThreatHunterSvc.exe.
Detection QuestionOperational SignificanceTelemetry Signals & Filters
Unexpected domain user logon to VBR?Flaw requires authenticated domain identityWindows Security Event ID 4624 (Logon Type 3) from non-admin accounts
Veeam service spawned unusual processes?Exploitation spawns shells or LOLBinsEvent ID 4688, Sysmon Event ID 1 (parent *Veeam* -> child cmd.exe, powershell.exe)
VBR server initiated unexpected outbound connections?Reverse callback to attacker listener / stagingSysmon Event ID 3, Firewall logs (outbound high ports to untrusted IPs)
Service account accessed resources outside backup windows?Credential reuse from backup secretsEDR identity telemetry, Kerberos TGS requests outside scheduled backup windows
Repository retention or backup jobs modified?Attacker preparing environment for ransomwareVeeam audit logs, Event ID 4663 on backup repository storage

Deploy the following detection engineering artifacts across your SIEM, EDR, and network monitoring platforms:

title: Suspicious Process Creation by Veeam Threat Hunter Service
id: a89c45b2-3f12-4891-b952-cve202644963
status: production
description: Detects unexpected child processes spawned by VeeamThreatHunterSvc.exe, indicative of CVE-2026-44963 exploitation.
references:
- https://www.veeam.com/kb4869
- https://www.miggo.io/post/the-backup-that-backfired-how-one-whitelisted-objref-hands-any-veeam-domain-user-system-cve-2026-44963
author: Hermes Security Research Team
date: 2026-06-11
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\VeeamThreatHunterSvc.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\mshta.exe'
- '\certutil.exe'
- '\whoami.exe'
- '\net.exe'
- '\net1.exe'
condition: selection
fields:
- ComputerName
- User
- ParentImage
- Image
- CommandLine
falsepositives:
- None observed in default enterprise deployments.
level: critical
tags:
- attack.execution
- attack.t1059
- attack.lateral_movement
- attack.t1210
- cve.2026_44963

8. Defensive Engineering & 10-Step Hardening Framework

Section titled “8. Defensive Engineering & 10-Step Hardening Framework”

Organizations operating Veeam Backup & Replication must implement the following remediation hierarchy immediately.

Apply the official vendor patch from Veeam:

  • Patch Package: Update to Veeam Backup & Replication 12.3.2.4854 (available via Veeam KB4869).
  • What the Patch Modifies: The hotfix updates Veeam.Backup.ThreatHunter.Service.dll to excise System.Runtime.Remoting.ObjRef from whitelist.txt, enforces bidirectional channel inspection on both request and reply streams, and tightens authentication controls to require local administrative privilege rather than generic BUILTIN\Users.

8.2 Priority 2: Immediate Network Perimeter Isolation

Section titled “8.2 Priority 2: Immediate Network Perimeter Isolation”

If maintenance windows prevent immediate binary patching, implement host-based or network firewall access control lists (ACLs) on the backup server:

Terminal window
# PowerShell script to block inbound access to TCP 6175 from remote endpoints
New-NetFirewallRule -DisplayName "Hermes-Mitigation-Block-Veeam-Port-6175" `
-Direction Inbound `
-LocalPort 6175 `
-Protocol TCP `
-Action Block `
-RemoteAddress Any `
-Profile Any `
-Description "Emergency mitigation for CVE-2026-44963: Blocks external access to VeeamThreatHunterSvc"

Note: Port 6175 is used exclusively for internal threat hunting inter-process communication on the local VBR server. Blocking external network access to port 6175 does not interrupt scheduled backup jobs, tape archiving, or replication data streams.

8.3 Priority 3: Service Deactivation (Zero-Impact Workaround)

Section titled “8.3 Priority 3: Service Deactivation (Zero-Impact Workaround)”

If firewall restrictions cannot be deployed, the Veeam Backup Threat Hunter Service can be temporarily stopped and disabled without breaking core backup storage and restoration operations:

Terminal window
Stop-Service -Name "VeeamThreatHunterSvc" -Force
Set-Service -Name "VeeamThreatHunterSvc" -StartupType Disabled

8.4 Priority 4: The 10-Step Strategic Hardening Framework

Section titled “8.4 Priority 4: The 10-Step Strategic Hardening Framework”
StepSecurity ControlOperational Objective
1Upgrade to Build 12.3.2.4854+Eliminates confirmed vulnerability in legacy .NET Remoting pipeline
2Identify All Domain-Joined VBR HostsMap all backup servers exposing the BUILTIN\Users vulnerability condition
3Network Segmentation & Firewall ACLsRestrict port 6175 and management interfaces to dedicated bastion jumpboxes
4Sever User VLAN IngressRemove general corporate user network access to backup management interfaces
5Decouple from Production Active DirectoryRe-deploy backup servers in an isolated workgroup or dedicated Tier-0 forest
6Enforce MFA for All Backup OperatorsNeutralize impact of stolen domain credentials on backup management consoles
7Least Privilege Role HygieneRestrict Veeam roles; treat backup administrative accounts as Tier-0 identities
8High-Value Asset EDR MonitoringDeploy advanced EDR agents and ingest all process/network telemetry into SIEM
9Validate Recovery WorkflowsPerform automated sandbox restoration tests to ensure integrity post-patch
10Implement Hardened ImmutabilityEnforce Linux hardened repositories (chattr +i) or S3 Object Lock (Compliance)

9. Correlation with Historical Veeam Vulnerability Landscape

Section titled “9. Correlation with Historical Veeam Vulnerability Landscape”

CVE-2026-44963 is the culmination of a persistent threat pattern targeting enterprise backup planes:

CVEYearVulnerability Type & Affected ComponentOperational Relevance to CVE-2026-44963
CVE-2023-275322023Unauthenticated Credential Disclosure (Veeam Backup Service)Demonstrated that initial foothold on backup port allows stealing AD service account secrets
CVE-2024-407112024Pre-Auth Remote Code Execution via DeserializationWeaponized in active ransomware campaigns (Akira, Fog, Frag) to destroy enterprise recovery
CVE-2025-231202025Authenticated Domain User RCE on Backup ServerHighlighted the identical design flaw: domain membership granting low-privileged RCE
CVE-2025-489832025Critical RCE in Veeam Mount ServiceShowed repeated failure of domain-joined backup infrastructure service boundaries
CVE-2025-489842025Critical RCE on Domain-Joined Backup ServersDemonstrated that domain-joined trust models consistently undermine backup server security
CVE-2026-216662026Authenticated Domain User RCE on VBR Backup ServerSibling flaw in VBR 12.3.x / 13.0.x allowing domain accounts to gain full system control
CVE-2026-216682026Arbitrary File Manipulation on Backup RepositoriesAllowed low-privileged users to overwrite and destroy restore points directly
CVE-2026-449632026RCE via .NET Remoting ObjRef Deserialization CallbackThe definitive flaw: complete SYSTEM control via allowlisted deserialization reverse triggers