Full Report
Microsoft and Veeam are investigating a known issue that triggers connection errors on Windows 11 24H2 systems when restoring from Veeam Recovery Media. [...]
Analysis Summary
# Incident Report: Windows 11 Update Breaks Veeam Recovery Functionality
## Executive Summary
A recent Windows 11 update negatively impacted the functionality of Veeam backup and recovery solutions, leading to connection errors for users attempting data restoration. The core issue stems from a dependency on Microsoft components within the Veeam Recovery Media, resulting in failed RPC calls and SSPI errors when initiating recovery operations. A temporary workaround suggests using Recovery Media generated from older, unaffected Windows 11 builds while Microsoft and Veeam investigate a permanent fix.
## Incident Details
- Discovery Date: Not explicitly stated, but implied shortly after the deployment of the problematic Windows 11 update.
- Incident Date: Corresponds with the release/installation of the specific Windows 11 update causing the compatibility break.
- Affected Organization: Veeam customers utilizing Windows 11 for backup/restore operations.
- Sector: IT Infrastructure/Data Management/Backup & Recovery.
- Geography: Global (Affects all users of the impacted Windows 11 version).
## Timeline of Events
### Initial Access
- Date/Time: N/A (Not an external attack, but a software incompatibility event).
- Vector: A mandatory or routine Windows 11 operating system update from Microsoft.
- Details: The update modified underlying OS components relied upon by Veeam Recovery Media.
### Lateral Movement
- N/A
### Data Exfiltration/Impact
- Impact: Inability to perform data or bare-metal restores via newly generated Veeam Recovery Media on systems running the patched Windows 11 build.
- Errors observed: "The remote procedure call failed and did not execute" (for SMB shared folder restores) and errors involving "Local Security Authority cannot be contacted" or "A call to SSPI failed" (for general recovery).
### Detection & Response
- Detection: Users attempting recovery operations reported errors to Veeam support or forums.
- Response actions taken: Veeam published an advisory acknowledging the known issue and its root cause (dependency on Windows RE components), and provided a temporary workaround.
## Attack Methodology
This was an unintended software defect, not a malicious attack. The following categories are marked as Not Applicable (N/A) as no threat actor was involved.
- Initial Access: N/A
- Persistence: N/A
- Privilege Escalation: N/A
- Defense Evasion: N/A
- Credential Access: N/A
- Discovery: N/A
- Lateral Movement: N/A
- Collection: N/A
- Exfiltration: N/A
- Impact: Inoperability of critical disaster recovery functions relying on the updated Windows environment.
## Impact Assessment
- Financial: Potential costs related to extended downtime or manual recovery efforts due to the inability to use standard recovery tools.
- Data Breach: None reported; this was a operational failure, not a data compromise incident.
- Operational: Significant disruption to disaster recovery capabilities for environments running the affected Windows 11 builds.
- Reputational: Temporary damage to trust in the reliability of recovery processes immediately following OS updates.
## Indicators of Compromise
As this is a software defect, traditional IoCs are not applicable. The behavioral indicator is:
- Behavioral indicators: Failure of Veeam Recovery Media operations resulting in SSPI or RPC connection errors when trying to contact services like the Local Security Authority.
## Response Actions
- Containment measures: None, as the underlying cause is external (Microsoft update).
- Eradication steps: Not applicable while waiting for a vendor-specific patch.
- Recovery actions: Users are advised to use Veeam Recovery Media generated *before* the problematic Windows 11 update (e.g., from build 26100.3037 or lower). This allows recovery until a permanent fix is issued by Microsoft/Veeam.
## Lessons Learned
- Key takeaways: Third-party recovery tools heavily reliant on proprietary Windows components (like Windows RE) are highly susceptible to breaking following routine, non-security related OS patches.
- What could have been done better: Organizations should strictly manage the OS version used when creating recovery media, potentially isolating specific build environments solely for generating recovery images.
## Recommendations
- Prevention measures for similar incidents: Implement strict change control and testing protocols for recovery platforms whenever a major Operating System update is applied, waiting for vendor confirmation (like Veeam's) of compatibility before deploying the update widely across production environments.
- Organizations should maintain access to at least one stable, older image of the OS build specifically designated for generating recovery media until vendor patches are confirmed.