Unit 42 Details Reverse-Engineering Effort to Add WebAuthn Support to Browser-Based RDP Client
Unit 42 Enables Phish-Resistant MFA for RDP by Reverse-Engineering WebAuthn Protocol
MITRE ATT&CK Techniques
Full Report
Executive Summary
Palo Alto Networks' Unit 42 has detailed a significant security engineering achievement: the successful integration of WebAuthn into a browser-based Remote Desktop Protocol (RDP) client. This research addresses a critical gap in securing legacy remote access, enabling the use of modern, phish-resistant Multi-Factor Authentication (MFA) for applications within an RDP session. By reverse-engineering Microsoft's undocumented MS-RDPEWA virtual channel protocol and developing a custom browser API, the team bypassed inherent limitations in standard web browser APIs. The result is the first RDP client outside of the native Windows ecosystem to support full WebAuthn redirection, allowing users to authenticate with local security keys (e.g., YubiKey) and platform authenticators (e.g., Touch ID, Windows Hello) to services inside the remote session. This development represents a major step forward in applying Zero Trust principles to legacy infrastructure, significantly hardening RDP against credential-based attacks.
The Technical Challenge: The WebAuthn-RDP Gap
The primary obstacle to integrating WebAuthn with RDP in a browser context lies in the security architecture of modern browsers. When a user in a remote RDP session attempts to authenticate to a service like Okta, the service's server initiates the WebAuthn ceremony. It generates a clientDataJSON object containing the origin (e.g., https://okta.com), a unique challenge, and other parameters. It then sends the SHA-256 hash of this object, known as clientDataHash, over the RDP virtual channel to the client.
The client's job is to pass this clientDataHash to a local authenticator (like a YubiKey) for signing. However, standard browser APIs, such as navigator.credentials.create(), are designed for security and isolation. They refuse to accept a pre-computed hash. Instead, the browser insists on creating its own clientDataJSON based on its own origin (e.g., chrome-extension://...). It then hashes this new object and sends it to the authenticator.
When the resulting signature is sent back to the remote service, the authentication fails because the hash signed by the authenticator does not match the original hash calculated by the server. This clientDataHash mismatch is a fundamental security feature to prevent cross-origin attacks, but it also makes direct redirection of WebAuthn ceremonies over RDP impossible with standard browser tools.
Technical Analysis: Reverse-Engineering MS-RDPEWA
To overcome this, Unit 42 researchers turned to reverse-engineering Microsoft's WebAuthn Virtual Channel Extension, specified as [MS-RDPEWA]. The protocol uses a Dynamic Virtual Channel (DVC) named Microsoft::Windows::RDP.Webauthn to transport CBOR-encoded WebAuthn requests between the server and client.
Initial analysis of the public specification revealed it was incomplete at the time of the research, documenting only four basic commands. The team used IDA Pro, augmented with AI-driven tooling to accelerate the process, to analyze the Windows implementation. This investigation uncovered undocumented internal code paths and two additional commands essential for full functionality:
GetCredentials(Command ID 9)GetAuthenticatorList(Command ID 12)
These commands, later added to the specification in March 2026 for Windows 11 24H2+, were critical for discovering and managing credentials stored on authenticators. By tracing the execution flow in the Windows RDP client (mstsc.exe), the researchers were able to map the protocol's behavior and understand how it interfaces with the underlying FIDO2 components, paving the way for a custom implementation.
The Solution: A Custom Browser API
Since no existing browser API (navigator.credentials, chrome.webAuthenticationProxy, WebHID) could fulfill the requirement of passing a pre-computed clientDataHash to the authenticator, the team built a custom solution. As developers of a Chromium-based browser (Prisma Browser), they were able to create a proprietary extension API.
This custom API mirrors the standard makeCredential() and getAssertion() methods but with one key difference: it allows the caller to supply the clientDataHash directly. This hash is then passed straight to Chromium's robust FIDO2 stack. This approach provides several advantages:
- Full Authenticator Support: It leverages Chromium's entire FIDO2 implementation, providing out-of-the-box support for USB, NFC, BLE, and platform authenticators (Touch ID, Windows Hello).
- Hybrid Transport: It includes support for Cloud-assisted Bluetooth Low Energy (caBLE), enabling phone-as-authenticator scenarios.
- No Native Helper: Unlike approaches using
libfido2(as seen in FreeRDP), this method does not require a separate native application to access hardware, keeping the entire solution contained within the browser sandbox.
This thin wrapper around Chromium's existing machinery provides a secure and powerful way to bridge the gap between the remote session and the user's local authenticators.
Impact Assessment
The business and security impact of this development is substantial. Remote Desktop Protocol remains a primary vector for lateral movement and initial access in enterprise networks, often targeted for its reliance on weaker, password-based authentication.
By enabling FIDO2/WebAuthn, organizations can now enforce phish-resistant MFA on RDP sessions accessing legacy applications. This directly mitigates the risk of credential theft, password spraying, and other attacks targeting Valid Accounts. For industries like finance, healthcare, and government that rely on on-premises applications, this provides a pathway to modernizing security without costly and complex application refactoring or relying on performance-degrading HTML5 gateways.
This capability strengthens Zero Trust architectures by ensuring that every connection, even to legacy systems, is protected by strong, verifiable identity, regardless of the user's location or device.
IOCs — Directly from Articles
No Indicators of Compromise (IOCs) are associated with this security research report.
Cyber Observables — Hunting Hints
The following patterns could help identify and monitor the usage of WebAuthn over RDP in an environment.
Microsoft::Windows::RDP.WebauthnMicrosoft::Windows::RDP.Webauthn channel is CBOR-encoded. Monitoring for this traffic pattern can help identify authentication events.mstsc.exeDetection & Response
While this research describes a defensive improvement, security teams can adapt their monitoring strategies to account for this new capability and detect potential misuse of RDP authentication.
- Monitor RDP Virtual Channels: Implement monitoring for the creation and use of the
Microsoft::Windows::RDP.WebauthnDVC. While its presence is benign in a properly configured environment, an unexpected appearance or anomalous traffic patterns could warrant investigation. - Correlate with Endpoint Logs: Correlate network-level RDP authentication events with endpoint process logs (e.g., Windows Event ID 4688). This can help attribute authentication activity to specific processes and users.
- Baseline Authentication Behavior: Establish a baseline for normal RDP authentication methods and user behavior. An environment transitioning to WebAuthn should see a corresponding decrease in NTLM or Kerberos authentication events for RDP. Deviations from this baseline could indicate misconfigurations or fallback to weaker protocols.
Defensive techniques from the D3FEND framework, such as Network Traffic Analysis (D3-NTA) and Process Analysis (D3-PA), are foundational for building a robust RDP monitoring capability.
Mitigation
The primary mitigation is the adoption of the technology itself. To secure RDP access and defend against credential-based attacks, organizations should prioritize the following:
- Deploy Phish-Resistant MFA: Implement FIDO2/WebAuthn for all remote access, including RDP. Utilize solutions like the browser-based client described in the research to extend this protection to legacy applications.
- Enforce Strong Authentication Policies: Mandate the use of MFA for all accounts, especially privileged ones and those with remote access capabilities. This is a core principle of Multi-factor Authentication (M1032).
- Network Segmentation: Restrict RDP access to and from specific jump hosts or management zones. Do not expose RDP directly to the internet. This aligns with Network Segmentation (M1030) to contain lateral movement.
- Regularly Audit RDP Access: Continuously audit and review accounts and systems with RDP access. Remove unnecessary access and apply the principle of least privilege, as recommended by User Account Management (M1018).
Timeline of Events
MITRE ATT&CK Mitigations
Multi-factor Authentication
Implementing phish-resistant MFA, such as the FIDO2/WebAuthn method detailed in the research, is the most effective defense against credential compromise for RDP access.
Mapped D3FEND Techniques:
User Account Management
Enforcing strong authentication policies and the principle of least privilege for all user accounts, especially those with remote access privileges, reduces the attack surface.
Network Segmentation
Isolating RDP access points behind jump hosts or gateways and strictly controlling network paths provides an additional layer of defense by containing potential breaches.
Running RDP clients within a sandboxed browser environment, as demonstrated in the research, limits the potential impact of a compromised client or session on the host machine.
Mapped D3FEND Techniques:
D3FEND Defensive Countermeasures
Organizations should prioritize the deployment of phish-resistant MFA for all remote access, especially for protocols like RDP that are frequent targets for credential-based attacks. This research demonstrates the feasibility of using browser-based clients to extend modern WebAuthn/FIDO2 capabilities to legacy on-premises applications accessed via RDP. The implementation should focus on using hardware security keys (YubiKey, etc.) or platform authenticators (Windows Hello, Touch ID) to protect against phishing and credential theft. Security teams should configure conditional access policies to mandate the use of these strong authenticators for all RDP sessions, particularly for privileged users and access to sensitive systems. This approach directly hardens the authentication process for RDP, moving beyond passwords and one-time codes to a more secure, unphishable standard, thereby significantly reducing the risk of unauthorized access via compromised credentials.
To complement strong authentication, security teams should implement Network Traffic Analysis (NTA) focused on RDP connections. Monitor for the creation and use of the Microsoft::Windows::RDP.Webauthn Dynamic Virtual Channel (DVC). While its presence is expected in environments using this feature, establishing a baseline of normal activity is crucial. Configure detection rules to alert on anomalies, such as WebAuthn DVC traffic originating from unauthorized subnets or at unusual times. Furthermore, analyze the metadata of RDP sessions (e.g., source/destination IPs, session duration, data transferred) and correlate it with authentication logs. An alert could be triggered if an RDP session, authenticated with strong MFA, begins exhibiting behavior consistent with lateral movement, such as connecting to multiple new hosts. This provides a critical detection layer to spot potential misuse of a legitimately authenticated session.
In the context of this research, Application Configuration Hardening involves securing the entire RDP ecosystem. This starts with hardening the RDP servers themselves by disabling unused virtual channels and enabling Network Level Authentication (NLA). For the client side, using a managed, Chromium-based browser like Prisma Browser allows for centralized policy enforcement. Administrators can create policies that mandate the use of the WebAuthn redirection feature and disable fallback to weaker authentication methods. This ensures that users cannot bypass the intended security controls. Hardening should also include restricting which users and devices are permitted to initiate RDP sessions and ensuring that the browser and its extensions are always up-to-date to protect against unrelated client-side vulnerabilities. This creates a hardened, policy-driven environment for remote access that minimizes the attack surface.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.