Author
Windows has supported computer telephony integration for decades, providing applications with the ability to manage phone devices, lines, and calls. While modern deployments increasingly rely on cloud-based telephony solutions, classic telephony services remain available out of the box in Windows and continue to be used in specialized environments. As a result, legacy telephony components still form part of the default Windows attack surface.
This research explores a vulnerability I discovered in the Telephony Service’s server mode, which allows low-privileged client to write arbitrary data to files accessible by the service and, under certain conditions, achieve remote code execution.
Windows Telephony Overview
Windows exposes telephony functionality through the Telephony Application Programming Interface (TAPI), which allows user-mode applications to interact with telephony devices and services via a unified abstraction layer.
TAPI exists in two primary forms: TAPI 2.x, which provides a procedural C-style API, and TAPI 3.x, which is implemented using COM. While the APIs differ, both rely on the same underlying architecture: applications communicate with the TAPI runtime, which forwards requests to Telephony Service Providers (TSPs).
TSPs are vendor-supplied components that encapsulate device- or service-specific logic and interface with the underlying telephony backend, such as physical telephony hardware, PBX systems, or VoIP endpoints. From the perspective of client applications, these differences are hidden behind the TAPI abstraction.
What is Telephony Service
Applications interact with the Windows telephony stack either by calling TAPI 2.x functions exported by tapi32.dll or by using the TAPI 3.x COM interfaces provided by tapi3.dll. In both cases, these libraries mostly act as client-side wrappers: they marshal requests and forward them to a system service that actually implements the telephony logic.
That service is the Telephony service (TapiSrv). It implements the actual TAPI functionality and exposes it to client applications through the tapsrv RPC interface. When an application invokes a TAPI call, the request is ultimately handled by TapiSrv, which selects the appropriate TSP and orchestrates the corresponding low-level interactions.
The service runs under the NETWORK SERVICE account and is configured with a manual startup type, but is automatically started on demand when a process first invokes a TAPI request via tapi32.dll or tapi3.dll. The whole implementation resides inside tapisrv.dll library.
(The diagram from MSDN is outdated but it provides the general understanding)
TAPSRV RPC Interface
Overview
Communication between TAPI clients and the Telephony service occurs over a classic MSRPC interface named tapsrv. The corresponding protocol, MS-TRP, is publicly documented. By default, this interface is restricted to local callers only.
On Windows Server systems, however, TAPI can be configured to accept remote client connections. This behavior is controlled by theHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\Server\DisableSharing
registry value and can also be managed through the Telephony MMC snap-in (TapiMgmt.msc).