Windows Network Services Internals: Jean-Baptiste Marchand
Windows Network Services Internals: Jean-Baptiste Marchand
Next
Revision History
22 October 2003
Initial version.
5 July 2004
Major update
19 October 2004
Port to the docbook typesetting system
20 January 2005
Major update of the NULL sessions section, including new information about Windows XP SP2 and
Windows Server 2003 SP1
19 March 2005
Additional details about NULL session restrictions for samr and lsarpc interfaces on Windows XP and
Windows Server 2003 (including for Active Directory domain controllers)
31 May 2005
Many small fixes, additions and reordering of sections
May 2006
Major update: new MSRPC interfaces, Windows Vista content (SMB 2.0, new MSRPC interfaces),
documentation of Windows API, MSRPC vulnerabilities section, MSRPC and DCOM network traffic
sections, sections reorganization, new naming convention for generated HTML pages, URL updates.
$LastChangedDate: 2006-05-22 13:21:48 +0200 (Mon, 22 May 2006) $
Last update
Table of Contents
1. Introduction
2. TCP/IP stacks
2.1. Introduction to Windows TCP/IP stacks
2.2. Windows 2000/XP/Server 2003 TCP/IP stack
2.3. No privileged ports
2.4. Ephemeral ports allocation
2.5. Identifying opened ports
2.5.1. netstat command
2.5.2. Identifying processes behind sockets
2.6. Sockets binding and hijacking
2.6.1. SO_EXCLUSIVEADDRUSE socket option
2.6.2. Example of multiple bindings: NetBT driver in Windows NT 4.0 SP6a
2.6.3. Multiple sockets bindings
2.6.4. What happens when SO_EXCLUSIVEADDRUSE is not used?
2.6.5. Windows services and drivers protected against socket hijacking
2.6.6. Global protection against socket hijacking
2.6.7. Diagnosing socket binding problems
2.7. The missing network loopback interface
2.8. Windows Vista TCP/IP stack
3. SMB/CIFS and SMB 2.0
3.1. SMB/CIFS and SMB 2.0 protocols
3.2. NetBIOS over TCP/IP
3.3. SMB transports
3.4. Vulnerabilities in Microsoft SMB/CIFS implementation
4. MSRPC, a.k.a. Microsoft implementation of DCE RPC
4.1. Introduction to MSRPC
4.2. DCE RPC Interface
4.3. MSRPC transports
4.4. MSRPC security model
4.5. RPC services registration
4.6. MSRPC over SMB
4.6.1. Named pipes
4.6.2. Named pipes used as MSRPC endpoints
4.6.3. Well-known MSRPC named pipes
4.7. NULL sessions
4.7.1. Introduction
4.7.2. Enabling NULL sessions restrictions
4.7.3. The ANONYMOUS LOGON network logon session
4.7.4. Restrictions at the share level
4.7.5. Restrictions on named pipes (IPC$ share)
4.7.6. Hardcoded named pipes
4.7.7. Named pipes permissions
4.7.8. Named pipes firewall in Windows XP SP2, Windows Server 2003 SP1 and later
versions
4.7.9. NULL sessions restrictions settings in Windows 2000
4.7.10. NULL sessions restrictions settings in Windows XP and Windows Server 2003
4.7.11. NULL session restrictions for the samr interface in Windows XP and Windows
Server 2003
4.7.12. NULL session restrictions for the lsarpc interface in Windows XP and Windows
Server 2003
4.7.13. NULL sessions restrictions for the samr interface on Active Directory domain
contollers
4.7.14. NULL sessions restrictions for the lsarpc interface on Active Directory domain
contollers
4.7.15. NULL sessions restrictions of server and workstation RPC operations
4.8. MSRPC over TCP/IP
4.8.1. Portmapper RPC service
4.8.2. RPC interfaces supported by the rpcss service
4.8.3. DCOM-related RPC interfaces running in the rpcss service
4.8.4. ORPC interfaces running in the rpcss service
4.9. Windows core MSRPC interfaces
4.9.1. lsarpc interface
4.9.2. samr interface
4.9.3. netlogon interface
4.9.4. drsuapi interface
4.9.5. dssetup interface
4.9.6. eventlog interface
4.9.7. pnp interface
4.9.8. srvsvc interface
4.9.9. svcctl interface
4.9.10. winreg interface
4.9.11. wkssvc interface
4.10. Windows services MSRPC interfaces
4.10.1. Active Directory domain controllers RPC services
4.10.2. Computer Browser service
4.10.3. DCOM Server Process Launcher
4.10.4. Distributed File System service
4.10.5. DNS server
4.10.6. Exchange RPC services
4.10.7. Exchange RPC services in Active Directory domains
4.10.8. File Replication service
4.10.9. IIS services
4.10.10. Inter-site Messaging service
4.10.11. Message Queuing and Distributed Transaction Coordinator services
4.10.12. Messenger service
4.10.13. NetDDE service
4.10.14. RPC locator service
4.10.15. Scheduler service
4.10.16. Spooler service
4.10.17. WINS service
4.11. Other MSRPC interfaces
4.11.1. Application Management service
4.11.2. Certificate services
4.11.3. Client Service for NetWare
4.11.4. Cryptographic Services service
4.11.5. DHCP Client service
4.11.6. DHCP Server service
4.11.7. Distributed Link Tracking Client service
4.11.8. Distributed Link Tracking Server service
4.11.9. DNS Client service - Windows 2000
4.11.10. DNS Client service - Windows XP and later versions
4.11.11. EFS
4.11.12. Fax server
4.11.13. File Server for Macintosh
4.11.14. IPsec Policy Agent service - Windows 2000
4.11.15. IPsec Services service - Windows XP and later versions
4.11.16. License Logging service
4.11.17. Microsoft SQL Server
4.11.18. Protected storage service
4.11.19. Routing and Remote Access service
4.11.20. Secondary Logon service
4.11.21. Security Configuration Editor Engine
4.11.22. SSDP Discovery Service service
4.11.23. System Event Notification service
4.11.24. Telephony service
4.11.25. Terminal Server service
4.11.26. WebClient service
4.11.27. Windows Audio service
4.11.28. Windows File Protection
4.11.29. Windows Security Center
4.11.30. Windows Time service
4.11.31. Winlogon process - Windows 2000
4.11.32. Winlogon process - Windows Server 2003
4.11.33. Wireless Configuration service
4.12. MSRPC interfaces introduced in Windows Vista
4.12.1. Group Policy Client Service
4.12.2. Network Location Awareness
4.12.3. Network Store Interface
4.12.4. Parental controls
4.12.5. Peer Networking Identity Manager
4.12.6. Remote Registry Service
4.12.7. Windows event collector service
4.12.8. Windows event logging service
4.12.9. Windows Firewall
4.12.10. Windows Wireless LAN 802.11 Auto Configuration Service
4.12.11. Wired Autoconfiguration Service
4.13. Implication of multiple RPC services in one process
4.13.1. Win32 services hosting
4.13.2. Example of multiple RPC services in one process
4.13.3. Implications of running multiple RPC services in one process
4.14. RPC services protection
4.15. RPC interfaces restriction in Windows XP SP2, Windows Server 2003 SP1 and later
versions
4.16. MSRPC vulnerabilities
4.17. MSRPC network traffic
4.17.1. MSRPC network traffic analysis with Ethereal
4.17.2. MSRPC network traffic analysis in Network Intrusion Prevention Systems
4.17.3. MSRPC network traffic analysis in Firewalls
4.18. DCOM
4.18.1. COM interfaces
4.18.2. DCOM network traffic
5. Conclusion
Bibliography
List of Tables
Next
Chapter 1. Introduction
Chapter 1. Introduction
Prev Next
Chapter 1. Introduction
The aim of this paper is to document some not well-known characteristics of Windows systems (based
on the NT kernel, i.e Windows NT, Windows 2000, Windows XP and Windows Server 2003) TCP/IP
stack and network services.
The first section of the paper focuses on Windows systems TCP/IP stack, highlighting some specificities
that are not well known.
The second section briefly mentions the SMB/CIFS protocol, which is probably the most important
network protocol on Windows systems (not to be confused with NetBIOS over TCP/IP, as frequently
seen, which is just a transport protocol for SMB/CIFS). The reference documentation for SMB/CIFS is
Christopher Hertel's book, Implementing CIFS [1]
The third section deals with MSRPC, a core Windows subsystem that implements a remote procedure
call method, used for local processes communication as well as remote procedures calls.
In addition to the present paper, other presentations and documents related to Windows network services
are also available:
Prev Next
Windows network services internals Home Chapter 2. TCP/IP stacks
Chapter 2. TCP/IP stacks
Prev Next
Prev Next
Chapter 1. Introduction 2.1. Introduction to Windows TCP/IP
Home
stacks
2.1. Introduction to Windows TCP/IP stacks
Prev Chapter 2. TCP/IP stacks Next
All Windows NT versions up to Windows XP and Windows Server 2003 shipped with the first
generation of Windows TCP/IP stack. Windows Vista and Windows Server "Longhorn" include the
second generation of Windows TCP/IP stack.
Prev Up Next
Chapter 2. TCP/IP stacks 2.2. Windows 2000/XP/Server 2003
Home
TCP/IP stack
2.2. Windows 2000/XP/Server 2003 TCP/IP stack
Prev Chapter 2. TCP/IP stacks Next
In addition, several articles published in the Cable Guy TechNet column [2] document with details
features of the TCP/IP stack:
Prev Up Next
2.1. Introduction to Windows TCP/IP 2.3. No privileged ports
Home
stacks
2.3. No privileged ports
Prev Chapter 2. TCP/IP stacks Next
Windows systems do not implement privileged ports. As a consequence, anybody can bind a TCP or
UDP server on a low port. As explained later, this has some serious security implications.
Prev Up Next
2.2. Windows 2000/XP/Server 2003 2.4. Ephemeral ports allocation
Home
TCP/IP stack
2.4. Ephemeral ports allocation
Prev Chapter 2. TCP/IP stacks Next
In the TCP/IP model, dynamic ports are typically used as source port by a TCP or UDP client, to
communicate with a remote TCP or UDP server, using a well-known port as destination port. In
Windows systems, dynamic ports are also used by RPC services (in that case, a portmapper service is
needed to find the appropriate RPC service).
When an application or driver requests a dynamic TCP or UDP port from the TCP/IP driver, the
allocated port belongs by default to the 1025-5000 range (port 1024 is apparently never used on
Windows systems).
The upper limit of this range can be changed, modifying the following registry value:
Key: HKLM\SYSTEM\CCS\Services\TcpIp\Parameters\
Value: MaxUserPort (REG_DWORD)
Default value: 5000 (decimal)
This range is shared for TCP and UDP ports. Moreover, dynamic ports are allocated incrementally. For
example, if an application requests a TCP port and obtains TCP port 1025, the next application
requesting a UDP port will obtain port 1026.
Exclusion from the dynamic port range can be configured with the ReservedPorts registry value:
Key: HKLM\SYSTEM\CCS\Services\TcpIp\Parameters\
Value: ReservedPorts (REG_MULTI_SZ)
Configuring this value can be necessary when some services need a fixed port in the lower part of the
dynamic range, like 1080/tcp for a SOCKS proxy or 1433/tcp and 1434/udp for MS SQL Server.
Otherwise, such ports may be dynamically allocated before services startup, which would cause the
service start failure.
However, it seems that the ReservedPorts registry value is also used by the Windows 2000 IPv4 NAT
driver [4], to determine which range can be used for source ports of NATed connections.
Prev Up Next
2.3. No privileged ports Home 2.5. Identifying opened ports
2.5. Identifying opened ports
Prev Chapter 2. TCP/IP stacks Next
Prev Up Next
2.4. Ephemeral ports allocation Home 2.5.1. netstat command
2.5.1. netstat command
Prev 2.5. Identifying opened ports Next
Systems implementing the TCP/IP protocol typically include the netstat utility, which can be used, among other things, to
list opened sockets.
● Before Windows NT 4.0 SP3, netstat does not display listening TCP ports [5]
● On Windows NT 4.0, netstat displays TCP ports as listening, when sockets are only bound to UDP ports [6]
The second bug can lead to suprising netstat outputs on Windows NT 4.0 systems. One particularly odd result is that TCP
port 135 (used by the rpcss service, as explained later) is displayed twice in netstat outputs:
This is because the rpcss service opens both ports 135/tcp and 135/udp. But, with the bug aforementionned, 135/tcp is
displayed a second time. This explains why 135/tcp appears twice.
Another serious bug exists in all versions of Windows NT systems before Windows Server 2003 and Windows XP SP2:
for each outgoing TCP connection established from a Windows system, the local source port is displayed as LISTENING
[7].
In the following example, a TCP connection was established to port 22 of a remote server. The TCP/IP driver allocated
port 1367 as source port for the connection. In the netstat output, the port appears in the LISTENING state:
However, this port is not really in the LISTENING state, i.e, it is not possible to establish a new TCP connection on port
1367. Using hping [8] to send a TCP segment with the SYN flag set, a TCP segment with the RST-ACK flags set is
returned:
The Winsock API (implementation of BSD sockets API on Windows systems) is implemented on TCP/IP using the Afd
driver, which uses the TDI (Transport Driver Interface) API to communicate with the TCP/IP driver.
To implement an outgoing TCP connection, the Afd driver creates two TDI objets:
Using a simple TCP client (nc.exe, [9]) to establish a TCP connection to port 22 of a remote server:
C:\WINNT>nc -z 192.168.1.254 22
the implementation at the TDI level can be monitored, using the TDIMon tool [10]:
● line 1, a create request (IRP_MJ_CREATE) for a TDI address object is sent to the TCP/IP driver. The drivers
returns an object with 0x8246D3F0 address.
● from line 2 to line 6, handlers are associated with the object, for the different events that can occur. In particular,
line 4 associates a handler to receive notifications when data arrive on port 1038.
● line 8, 9 and 10 show the creation of the TDI object used to represent the outgoing TCP connection. On line 10,
the TDI_CONNECT command establishes the TCP connection to port 22 of the machine with 192.168.1.254 as
IP address.
Thus, it appears that at the TDI level, a TCP connection is implemented using two TDI objects:
The problem is that the GetTcpTable() API retrieving the content of the current TCP connections table incorrectly
translates the second TDI object as a TCP listening socket. As a consequence, the port is displayed as LISTENING by the
netstat command. Note that any tools using this API will report incorrect results. Thus, results of such tools must be
analyzed carefully, to filter ports reported as LISTENING. This bug has been fixed in Windows Server 2003 and in
Windows XP SP2.
Prev Up Next
2.5. Identifying opened ports Home 2.5.2. Identifying processes behind sockets
2.5.2. Identifying processes behind sockets
Prev 2.5. Identifying opened ports Next
Starting with Windows XP, the netstat command can be used with the -o option to identify which
process opened a given socket [12]. Starting with Windows XP SP2 and Windows Server 2003 SP1, the -
b option can be used instead of the -o option.
In October 2005, Microsoft documented the availability of a Windows 2000 update [13], adding support
for the -o netstat option.
On systems where the -o netstat option is not available, the following tools can be used:
These tools will give the PID (Process Identifier) of processes using sockets.
However, knowing the PID is not always enough to identify precisely which system component opened
a given socket, particularly in the following cases:
● Standard Windows services run in a few shared processes (services.exe, svchost.exe). The
aforementionned tools return the PID of the process but can not identify which service in a shared
process opened a given socket. It is then necessary to stop services inside the shared process, to
determine which service owns a given socket.
● Some sockets are reported as owned by the System process.
On a default Windows system, some sockets will be reported as owned by the System process (pid 8 on
Windows 2000, pid 4 on Windows XP and Windows Server 2003): these sockets are opened by drivers
communicating directly with the TCP/IP driver in kernel-mode.
It is not possible to statically identify which driver opened a given port. Thus, it is sometimes hard to
figure out why a port is opened when it has been opened by a driver. For example, on some Windows
systems, port 1025 (the first dynamic port) seems to be opened by an unknown driver at system startup.
For more information, a list of TCP and UDP ports used by Microsoft Server Products is available [15].
Prev Up Next
2.5.1. netstat command Home 2.6. Sockets binding and hijacking
2.6. Sockets binding and hijacking
Prev Chapter 2. TCP/IP stacks Next
As explained earlier, Windows TCP/IP stack does not implement privileged ports. More precisely, any
process can bind a socket to any port, even when a socket is already bound to a port. Thus, it becomes
possible to hijack a TCP server.
This kind of vulnerability was published for the first time in february 1998, in the security advisory NT
port binding security [17].
This advisory showed how, for example, any user could hijack the Windows NT 4 SMB server, binding
a TCP server on port TCP 139 using a specific IP address in the bind() call.
Microsoft released knowledge base article 194431 [21], mentionning the problem and stating that it was
fixed in Windows NT 4.0 Service Pack 4.
● it seems that Microsoft itself did not use this socket option in its servers (particularly, IIS 4 and
IIS 5)
● this socket option can not be used by drivers, which directly communicate with the TCP/IP
driver, without using the Winsock API.
Prev Up Next
2.5.2. Identifying processes behind 2.6.1. SO_EXCLUSIVEADDRUSE
Home
sockets socket option
2.6.1. SO_EXCLUSIVEADDRUSE socket option
Prev 2.6. Sockets binding and hijacking Next
Thus, when this socket option is used by an application before using the bind() function, no other
application will be able to bind to the same local address, even when the SO_REUSEADDR is used, as
does nc.exe.
As said earlier, the Winsock API is implemented by the Afd driver, which interacts with the TCP/IP
driver using the TDI interface. At the TDI level, TCP and UDP ports are represented by file objects.
The implementation of the SO_EXCLUSIVEADDRUSE socket option opens file objects in exclusive
mode, setting the ShareAccess parameter of the ZwCreateFile() function to 0. Thus, file objects
representing TCP and UDP ports can only be opened in exclusive mode, which correspond to exclusive
binding at the Winsock level.
Warning: before Windows 2000 SP4, Windows XP SP2 or Windows Server 2003, this socket option can
only be used by processes running with administrator credentials. This bug is documented in the
#870562 Microsoft knowledge base article [23].
Prev Up Next
2.6. Sockets binding and hijacking 2.6.2. Example of multiple bindings:
Home
NetBT driver in Windows NT 4.0 SP6a
2.6.2. Example of multiple bindings: NetBT driver in Windows NT 4.0 SP6a
Prev 2.6. Sockets binding and hijacking Next
Follows a demonstration of multiple bindings on a Windows NT 4.0 SP6a system. As NetBIOS over
TCP/IP is active on the system, TCP Port 139 is opened by the NetBT driver and bound to IP address
192.70.106.143:
Then, a nc.exe process is bound to the same port and same IP address:
The next TCP connection will be routed to the nc.exe process, hijacking the SMB server.
Using socat [18] to establish a TCP connection to port 139 of IP address 192.70.106.143, the blah string
is sent:
C:\>
An interesting way to exploit this vulnerability would be to setup an SMB redirector, that would redirect
all SMB trafic to another machine [19].
A fix for the NetBT driver was finally introduced in the C2 Update Post-SP6a hotfix, because one
TCSEC C2 requirement mandates that an unprivileged user-mode program should not be able to listen to
ports used by Windows NT services [20].
This fix is also available in the Windows NT 4.0 Security Rollup Package. To enable it, the following
registry value must be configured:
Key: HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Value: EnablePortLocking (REG_DWORD)
Content: 0 to disable protection (default), 1 to enable protection
Prev Up Next
2.6.1. SO_EXCLUSIVEADDRUSE 2.6.3. Multiple sockets bindings
Home
socket option
2.6.3. Multiple sockets bindings
Prev 2.6. Sockets binding and hijacking Next
Considering TCP servers, there are different case of multiple sockets bindings, that can occur when the
first server did not specify SO_EXCLUSIVEADDRUSE and when the second server specifies
SO_REUSEADDR is used by the second server
● One TCP server bound to all interfaces (INADDR_ANY or 0.0.0.0) and then, a second TCP
server bound to a specific interface
● One TCP server bound to a specific interface and then, a second TCP server bound to all
interfaces
● One TCP server bound to a specific interface and then, a second TCP server to another specific
interface
● One TCP server bound to a specific interface and then, a second TCP server bound to the same
specific interface
The first case is a serious security problem. This means that if a TCP server is bound to all interfaces, it
is later possible to start a TCP server bound to the same port but on a specific interface. The second TCP
server will receive all TCP connection segments sent to the IP adress of the specific interface.
As the TCP/IP stack does not implement privileged ports, it is possible to disrupt any TCP servers using
this technique.
The second case is not a security problem. The second server will receive TCP connection segments sent
to any IP address different from the IP address of the specific interface.
The third case is not a security problem, as the two servers are listening on different specific interfaces.
The fourth case is problematic because two TCP servers are bound to exactly the same local address
(same port and same IP address). The MSDN documentation [22] explains that in that case, the behavior
is undefined as to which sockets will receive incoming connection requests.
However, it seems that on Windows NT 4.0, the second server will receive packets, which is the worst
case because this means that the first server is hijacked. This is what happens with the NeBT driver on
Windows NT 4.0 SP6a, as seen earlier.
For instance, the HTTP server part of Internet Information Services (IIS) 5, shipped with Windows
2000, listens by default on all network interfaces on ports 80 and 443. It is possible to hijack the HTTP
server of IIS 5 with a TCP server bound to the IP address of a specific interface.
Even more interesting, when a TCP server listens on all interfaces, it is possible to silently intercept TCP
traffic, binding a second TCP server to intercept trafic and redirecting to the loopback address, to finally
deliver date to the hijacked server (thanks to Franck Davy for suggesting this).
On a Windows 2000 server with IIS 5, the HTTP service listens on all interfaces:
Using fpipe, a second TCP server is bound to IPv4 address 192.70.106.142 and configured to redirect
traffic to the loopback address (127.0.0.1), with TCP port 80 as destination:
The second server receives the connection on port 80 and redirect data to the IIS 5 server, using
127.0.0.1 as destination address:
Connection accepted from 192.70.106.76 port 1077
Attempting to connect to 192.70.106.76 port 1077
Pipe connected:
In: 192.70.106.76:1077 --> 192.70.106.142:80
Out: 192.70.106.142:33014 --> 127.0.0.1:80
15 bytes received from inbound connection
16 bytes received from inbound connection
1 bytes received from inbound connection
273 bytes received from outbound connection
Outbound connection lost
Closing outbound connection
Closing inbound connection
The TCP client finally receives data sent by the IIS5 server:
[...]
Prev Up Next
2.6.3. Multiple sockets bindings 2.6.5. Windows services and drivers
Home
protected against socket hijacking
2.6.5. Windows services and drivers protected against socket hijacking
Prev 2.6. Sockets binding and hijacking Next
Most Windows 2000 (and later Windows NT versions) network services are protected with the
SO_EXCLUSIVEADDRUSE socket option:
● All RPC services that use TCP sockets (135/tcp, dynamic TCP ports in range 1025-5000)
apparently use the socket option
● MS SQL Server 2000 (1433/tcp)
All ports opened by Windows 2000 drivers (and later Windows NT version) correctly set the
ShareAccess parameter to 0 when calling ZwCreateFile();
Prev Up Next
2.6.4. What happens when 2.6.6. Global protection against socket
SO_EXCLUSIVEADDRUSE is not Home hijacking
used?
2.6.6. Global protection against socket hijacking
Prev 2.6. Sockets binding and hijacking Next
As explained earlier, to be protected against socket hijacking, applications must explicitly set the
SO_EXCLUSIVEADDRUSE socket option before calling bind().
A registry value exists under the Parameters key of the Afd driver, to globally enable the protection, as
if all applications specified the socket option:
Key: HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters\
Value: DisableAddressSharing
Content: 1 (to enable protection)
Prev Up Next
2.6.5. Windows services and drivers 2.6.7. Diagnosing socket binding
Home
protected against socket hijacking problems
2.6.7. Diagnosing socket binding problems
Prev 2.6. Sockets binding and hijacking Next
Diagnosing socket binding problems is easy when the return code of the bind() call is available. The typical return
codes are:
● WSAEADDRINUSE (10048): this typically means that the SO_REUSEADDR socket option was not used.
● WSAEACCES (10013): this means that socket hijacking protection was enabled (either with
SO_EXCLUSIVEADDRUSE or with DisableAddressSharing set to 1.
Most of the times, the bind() return code is not available. In that case, the TDIMon [10] tool can be used:
● When the WSAEADDRINUSE error is returned, TDIMon does not display anything, because this error code is
returned directly by the Afd driver, without ever communicating with the TCP/IP driver.
● When the WSAEACCES error is returned, TDIMon displays the SHARING_VIOLATION error, returned at
the TDI level
Prev Up Next
2.6.6. Global protection against socket 2.7. The missing network loopback interface
Home
hijacking
2.7. The missing network loopback interface
Prev Chapter 2. TCP/IP stacks Next
Thus, it is not possible to sniff network traffic using the typical Windows packet capture driver,
WinPcap [24].
However, TDIMon [10] can be used to see loopback traffic (but does not support network traffic
logging):
● Sending process
● Source and destination ports (source and destination IP address are typically 127.0.0.1)
● Length of sent data
NT Kernel Resources's Local Host Monitor [11] is similar to Sysinternals's TDIMon but also supports
data sent to the TCP/IP driver using the TDI interface, including loopback network data.
Another method to capture loopback network data is to use a Winsock LSP (Layered Service Provider).
The Ports Traffic Analyzer [25] is an example of such sniffer.
The Microsoft Loopback Adapter can be installed on Windows systems, to run network applications
when no physical adapter is present or active on the system [26]. This adapter is not the equivalent of a
network loopback interface and IPv4 address 127.0.0.1 can not be assigned to it. Also, it is not possible
to sniff network traffic on it, at least with WinPcap.
Prev Up Next
2.6.7. Diagnosing socket binding 2.8. Windows Vista TCP/IP stack
Home
problems
2.8. Windows Vista TCP/IP stack
Prev Chapter 2. TCP/IP stacks Next
Several issues of the Cable Guy Technet column document with more details features of the new stack:
● September 2005: Next Generation TCP/IP Stack in Windows Vista and Windows Server
"Longhorn"
● October 2005: Changes to IPv6 in Windows Vista and Windows Server "Longhorn"
● November 2005: Performance Enhancements in the Next Generation TCP/IP Stack
● January 2006: The New Windows Firewall in Windows Vista and Windows Server "Longhorn"
● March 2006: Policy-based QoS Architecture in Windows Server "Longhorn" and Windows Vista
● April 2006: Connecting to Wireless Networks with Windows Vista
● May 2006: Configuring IPv6 with Windows Vista
Prev Up Next
2.7. The missing network loopback Chapter 3. SMB/CIFS and SMB 2.0
Home
interface
Chapter 3. SMB/CIFS and SMB 2.0
Prev Next
Prev Next
2.8. Windows Vista TCP/IP stack Home 3.1. SMB/CIFS and SMB 2.0 protocols
3.1. SMB/CIFS and SMB 2.0 protocols
Prev Chapter 3. SMB/CIFS and SMB 2.0 Next
For a thorough explanation of the SMB/CIFS protocol, see the SMB chapter [27] of Christopher Hertel's
book, Implementing CIFS.
SMB 2.0 is the new version of SMB implemented in Windows Vista. For more information about SMB
2.0, see the SMB 2.0 pages on the Ethereal Wiki.
Prev Up Next
Chapter 3. SMB/CIFS and SMB 2.0 Home 3.2. NetBIOS over TCP/IP
3.2. NetBIOS over TCP/IP
Prev Chapter 3. SMB/CIFS and SMB 2.0 Next
The NetBIOS API uses names to identify network ressources. The nbtstat command can be used to
examine and configure NetBIOS names on a Windows system.
NetBIOS over TCP/IP in itself is just a transport protocol. However, as it is the typical transport protocol
for the SMB/CIFS protocol in Windows systems, it is often confused with the SMB/CIFS protocol,
which does the real work on Windows systems.
For technical details about NetBIOS over TCP/IP, the reference documentation is the NBT chapter [28]
of Christopher Hertel's book, Implementing CIFS.
Prev Up Next
3.1. SMB/CIFS and SMB 2.0 protocols Home 3.3. SMB transports
3.3. SMB transports
Prev Chapter 3. SMB/CIFS and SMB 2.0 Next
To identify which SMB transports are active on a Windows system, the net config rdr and net config srv
commands can be used. These commands use the NetWkstaTransportEnum() and
NetServerTransportEnum() Win32 API:
[...]
Workstation active on
NetbiosSmb (000000000000)
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102A495B2)
[...]
[...]
Server is active on
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102a495b2)
NetBT_Tcpip_{33227EBB-55A3-49EA-823D-51836B978EFD} (000102a495b2)
NetbiosSmb (000000000000)
NetbiosSmb (000000000000)
[...]
Note: Windows NT 4.0 and Windows 2000 systems apparently have a bug in the
NetServerTransportEnum() API, which retrieves server-side transports: each transport appears twice.
In Windows Vista, the output of the net config srv is as follows:
[...]
[...]
The raw SMB transport can not be disabled on a per-adapter basis. To completely disable it, the NetBT
driver must be stopped.
A Windows system with both SMB transports active tries to connect to 445/tcp and 139/tcp at the same
time. If the connection to 445/tcp is accepted, the connection to port 139 is closed (sending a TCP segment
with the RST flag set), i.e., raw SMB transport is preferred over NetBT transport [31].
Prev Up Next
3.2. NetBIOS over TCP/IP 3.4. Vulnerabilities in Microsoft SMB/
Home
CIFS implementation
3.4. Vulnerabilities in Microsoft SMB/CIFS implementation
Prev Chapter 3. SMB/CIFS and SMB 2.0 Next
Prev Up Next
3.3. SMB transports Chapter 4. MSRPC, a.k.a. Microsoft
Home
implementation of DCE RPC
Chapter 4. MSRPC, a.k.a. Microsoft implementation of DCE RPC
Prev Next
Prev Next
3.4. Vulnerabilities in Microsoft SMB/ 4.1. Introduction to MSRPC
Home
CIFS implementation
4.1. Introduction to MSRPC
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
MSRPC is the Microsoft implementation of the DCE RPC mechanism. In particular, Microsoft added
new transport protocols for DCE RPC, in particular the ncacn_np transport, which use named pipes
carried into the SMB protocol.
For an interesting story of Windows and how Microsoft chose to implement DCE RPC, see A brief
history of Windows [34].
For a general overview of the MSRPC architecture, see the RPC Technical Reference, What Is RPC?
and How RPC Works sections in the Windows Server 2003 Technical Library.
Prev Up Next
Chapter 4. MSRPC, a.k.a. Microsoft 4.2. DCE RPC Interface
Home
implementation of DCE RPC
4.2. DCE RPC Interface
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
For a detailed explanation of DCE RPC interface, see figure 2.2 [35] in the DCE RPC 1.1
documentation.
Prev Up Next
4.1. Introduction to MSRPC Home 4.3. MSRPC transports
4.3. MSRPC transports
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
In DCE-RPC (and thus MSRPC), transport protocols are identified with protocol sequences identifiers.
Windows systems typically use the following protocol sequences:
An endpoint is the entity used at the transport level to invoke remotely a RPC service. Endpoint nature is
specific to each protocol sequences:
Most LPC ports are MSRPC endpoints. Using the Winobj tool [36], you can see a list of LPC ports used
as MSRPC endpoints on a running system, under the RPC Control subdirectory of the NT kernel
Object Manager namespace.
However, not all TCP or UDP ports are MSRPC endpoints, as well as not all named pipes.
One method to identify if a TCP port, UDP port or named pipe is a MSRPC endpoint is to try to bind to
the RPC service supposedly listening on the supposed endpoint. If the bind operation fails or blocks,
then the tested endpoint is probably not a MSRPC endpoint.
The ifids tool, part of Todd Sabin's RPC Tools [37] can be used to identify RPC services endpoints. A
demonstration of this tool is given in [41].
Prev Up Next
4.2. DCE RPC Interface Home 4.4. MSRPC security model
4.4. MSRPC security model
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
The list of MSRPC security providers is stored under the following registry key:
Key: HKLM\SOFTWAWRE\Microsoft\Rpc\SecurityService\
When the SMB transport (ncacn_np) is used, there is no additional authentication at the MSRPC level.
Instead, the security context of the MSRPC session is derived from the authenticated SMB session
established previously.
Prev Up Next
4.3. MSRPC transports Home 4.5. RPC services registration
4.5. RPC services registration
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
When a RPC service listens on a TCP or UDP endpoint, it must register itself in the endpoint map
because TCP and UDP ports are dynamically allocated to RPC services.
To query the portmapper RPC service, the rpcdump tool [37] can be used. In the output of that
command, ncacn_ip_tcp and ncadg_ip_udp correspond to dynamically allocated ports.
Prev Up Next
4.4. MSRPC security model Home 4.6. MSRPC over SMB
4.6. MSRPC over SMB
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.5. RPC services registration Home 4.6.1. Named pipes
4.6.1. Named pipes
Prev 4.6. MSRPC over SMB Next
In Windows systems, named pipes in one of the available IPC (Inter-Process Communication)
mechanism. It can be used either locally or remotely.
Accesses to remote named pipes, contained in the IPC$ share, are carried into the SMB protocol.
Named pipes are implemented by a file system driver, npfs.sys. The PipeList [38] tool can be used to
enumerate the npfs namespace, to show which named pipes are opened on a local system. The FileMon
tool [39] is also able to monitor the named pipe filesystem activity, by selecting Named Pipes in the
Drives menu.
Some named pipes are implemented as aliases [40], i.e, they don't really exist in the npfs namespace.
Aliases names are stored in the registry:
Key: HKLM\SYSTEM\CurrentControlSet\Services\Npfs\Aliases\
Values: lsass, ntsvcs
Named pipes are protected by security descriptors, just like any Windows NT objects. The pipeacl tool
([42],[43]) be used to examine the content of security descriptors protecting named pipes.
Prev Up Next
4.6. MSRPC over SMB 4.6.2. Named pipes used as MSRPC
Home
endpoints
4.6.2. Named pipes used as MSRPC endpoints
Prev 4.6. MSRPC over SMB Next
Some named pipes are used as MSRPC endpoints, i.e, they are used to carry DCE RPC PDU (Protocol
Data Units). Compared to other RPC transports, the ncacn_np transport is different because it usually
does not involve authentication at the DCE RPC level. Instead, authentication information is obtained
from the SMB session established priorly.
However, it is possible to have unauthenticated DCE RPC sessions using SMB NULL sessions. In that
case, there is no authentication, neither at the SMB level nor at the DCE RPC level.
Also, contrary to RPC services listening on ncacn_ip_tcp or ncadg_ip_udp, the portmapper service is
generally not necessary for RPC services using named pipes, as the named pipe name usually identifies
the RPC interface.
Prev Up Next
4.6.1. Named pipes 4.6.3. Well-known MSRPC named
Home
pipes
4.6.3. Well-known MSRPC named pipes
Prev 4.6. MSRPC over SMB Next
The following table gives a list of named pipes that are used as endpoints by Windows RPC services.
The interface identifier associated to each named pipe represents the service typically accessed when a
given named pipe is used.
However, due to the fact that any endpoint in a given process can be used to reach any RPC service, it is
possible to use multiple RPC services using a single named pipe endpoint.
Prev Up Next
4.6.2. Named pipes used as MSRPC 4.7. NULL sessions
Home
endpoints
4.7. NULL sessions
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.6.3. Well-known MSRPC named 4.7.1. Introduction
Home
pipes
4.7.1. Introduction
Prev 4.7. NULL sessions Next
4.7.1. Introduction
NULL sessions refer to the possibility to use unauthenticated SMB sessions to the IPC$ share to gather
information anonymously, using RPC function calls carried into SMB.
SMB sessions are typically authenticated. However, it is possible to use an empty username and
password, which results in a NULL session, i.e an anonymous SMB session.
The MSRPC NULL sessions: exploitation and protection presentation is available to complement the
information found in this section.
Prev Up Next
4.7. NULL sessions 4.7.2. Enabling NULL sessions
Home
restrictions
4.7.2. Enabling NULL sessions restrictions
Prev 4.7. NULL sessions Next
In Windows NT, NULL sessions were used by processes running under the LOCALSYSTEM logon
session when they needed to establish a network logon session on a remote server.
Because processes running as LOCALSYSTEM did not have network credentials in Windows NT, the
only way to establish a network logon session on a remote server was to use an empty login and
password during SMB authentication.
It turned out that NULL sessions could be used to gather some sensible information anonymously.
Microsoft added NULL sessions restrictions in Windows NT 3.5. These restrictions are enabled by the
following registry value, which is enabled by default starting with NT 3.5:
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: RestrictNullSessAccess (REG_DWORD)
Content: 1 to enable NULL sessions restrictions (default value)
In recent Windows systems, this registry value (enabled by default) is also a security option:
The different NULL sessions restrictions are detailed in the next sections.
Prev Up Next
4.7.1. Introduction 4.7.3. The ANONYMOUS LOGON
Home
network logon session
4.7.3. The ANONYMOUS LOGON network logon session
Prev 4.7. NULL sessions Next
When a Windows systems starts, it creates several logon sessions (depending on Windows versions),
including a network logon session to represent anonymous access. This network logon session is known
as the ANONYMOUS LOGON network logon session.
Logon sessions created at startup by a Windows Server 2003 can be enumerated using the logonsessions
tool [44].
Z:\>logonsessions
Logonsesions v1.1
Copyright (C) 2004 Bryce Cogswell and Mark Russinovich
Sysinternals - wwww.sysinternals.com
Because the ANONYMOUS LOGON network logon session is created at startup, when a NULL
session is established, Windows does not need to create another logon session.
Hence, logon rights are not verified and it is not possible to prevent NULL sessions by removing the
network logon right for ANONYMOUS LOGON, as one might expect.
Prev Up Next
4.7.2. Enabling NULL sessions 4.7.4. Restrictions at the share level
Home
restrictions
4.7.4. Restrictions at the share level
Prev 4.7. NULL sessions Next
The first category of restrictions allows the administrator to configure which shares can be used
anonymously:
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionShares (REG_SZ)
This registry value is also set by a security option, starting with Windows XP:
On default Windows systems, this value contains the COMCFG and DFS$ shares.
The IPC$ share does not appear in this registry value. However, it is always possible to connect
anonymously to it. Restrictions for the IPC$ share are implemented at the named pipes level, as
described in the next section.
Prev Up Next
4.7.3. The ANONYMOUS LOGON 4.7.5. Restrictions on named pipes (IPC
Home
network logon session $ share)
4.7.5. Restrictions on named pipes (IPC$ share)
Prev 4.7. NULL sessions Next
The NullSessionPipes registry value is supposed to configure the list of named pipes that can be opened anonymously:
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionPipes (REG_SZ)
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionPipes (REG_SZ)
Default value: COMNAP COMNODE SQL\QUERY SPOOLSS LLSRPC EPMAPPER LOCATOR WINREG
On default Windows 2000 systems, there are two more named pipes (TrkWks and TrkSvr, opened by the Distributed Link
Tracking Client and Distributed Link Tracking Server services):
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionPipes (REG_SZ)
Default value: COMNAP COMNODE SQL\QUERY SPOOLSS LLSRPC EPMAPPER LOCATOR TrkWks TrkSvr
In Windows 2000 Service Pack 4 (SP4), the LLSRPC named pipe was removed, as documented by Microsoft [45]. Note
however that LLSRPC is removed only when SP4 is installed on an existing Windows 2000 installation, but NOT when SP4
is slipstreamed to create a Windows 2000 SP4 installation image.
Starting with Windows XP, this registry value can be set via a security option:
Prev Up Next
4.7.4. Restrictions at the share level Home 4.7.6. Hardcoded named pipes
4.7.6. Hardcoded named pipes
Prev 4.7. NULL sessions Next
In addition to named pipes that appear in the NullSessionPipes registry value, some additional named pipes are hardcoded
in the SMB server driver (srv.sys).
Thus, it is possible to open the lsarpc named pipe in the context of a NULL session (but not the lsass named pipe, even if
the first one is an alias of the second one, as explained earlier).
These harcoded named pipes were removed in the SMB server driver of recent Windows systems, starting with Windows
XP Service Pack 2 (SP2) and Windows Server 2003 Service Pack 1 (SP1).
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionPipes (REG_SZ)
Default value: COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, browser
As a consequence, it is no longer possible to open the following named pipes in the context of a NULL session in Windows
XP SP2:
● \pipe\lsarpc
● \pipe\samr
● \pipe\netlogon
● \pipe\wkssvc
● \pipe\srvsvc
On Windows Server 2003 SP1, netlogon, lsarpc, samr and browser have been explicitely added:
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\
Value: NullSessionPipes (REG_SZ)
Default value: COMNAP, COMNODE, SQL\QUERY, SPOOLSS, netlogon, lsarpc, samr, browser
As a consequence, it is no longer to open the following named pipes in the context of a NULL session in Windows Server
2003 SP1:
● \pipe\wkssvc
● \pipe\srvsvc
Prev Up Next
4.7.5. Restrictions on named pipes (IPC$ share) Home 4.7.7. Named pipes permissions
4.7.7. Named pipes permissions
Prev 4.7. NULL sessions Next
Named pipes are implemented by a filesystem driver in Windows NT, npfs.sys, which supports security
descriptors on each named pipe. These security descriptors are used to control access to named pipes. It
is possible to use the pipeacl tool ([42], [43]) to examine and modify security descriptors on named
pipes.
In Windows 2000, named pipes DACL (Discretionnary Access Control Lists) grant permissions to
EVERYONE and ADMINISTRATORS for most named pipes used as MSRPC endpoints. Because
ANONYMOUS LOGON is included in EVERYONE in Windows 2000, named pipes permissions allow
anonymous accesses.
E:\>pipeacl \??\pipe\lsarpc
Revision: 1
Reserved: 0
Control : 8004
Owner: BUILTIN\Administrators (S-1-5-32-544)
Group: SYSTEM (S-1-5-18)
Sacl: Not present
Dacl: 2 aces
(A) (00) 0012019b : Everyone (S-1-1-0)
(A) (00) 001f01ff : BUILTIN\Administrators (S-1-5-32-544)
In Windows XP and Windows Server 2003, DACL grant permissions to EVERYONE, ANONYMOUS
LOGON and ADMINISTRATORS. EVERYONE and ANONYMOUS LOGON are given exactly the
same permissions: permissions are thus exactly equivalent to Windows 2000 permissions (starting with
Windows XP, EVERYONE does not include ANONYMOUS LOGON so ANONYMOUS LOGON
must explicitely appear in ACL).
C:\>pipeacl \??\pipe\lsarpc
Revision: 1
Reserved: 0
Control : 8004
Owner: BUILTIN\Administrators (S-1-5-32-544)
Group: SYSTEM (S-1-5-18)
Sacl: Not present
Dacl: 3 aces
(A) (00) 001f01ff : BUILTIN\Administrators (S-1-5-32-544)
(A) (00) 0012019b : Anonymous (S-1-5-7)
(A) (00) 0012019b : Everyone (S-1-1-0)
It is possible to modify ACL on named pipes using pipeacl and typically either add a deny ACE for
ANONYMOUS LOGON in Windows 2000 or remove the ACE for ANONYMOUS LOGON in
Windows XP and Windows Server 2003.
When permissions are manually removed for ANONYMOUS LOGON for named pipes that are either
hardcoded in the SMB server driver or found in the NullSessionPipes registry value such as lsarpc, it is
no longer possible to open this pipe in the context of a NULL session.
To conclude, permissions on named permissions are typically not used for NULL sessions restrictions
because, by default, DACL allow accesses for ANONYMOUS LOGON. It is not really practical to
modify default DACL, given that modifications of DACL on named pipes are not persistent (because
named pipes are created by RPC services at startup).
Prev Up Next
4.7.6. Hardcoded named pipes 4.7.8. Named pipes firewall in
Home Windows XP SP2, Windows Server
2003 SP1 and later versions
4.7.8. Named pipes firewall in Windows XP SP2, Windows Server 2003 SP1 and later versions
Prev 4.7. NULL sessions Next
4.7.8. Named pipes firewall in Windows XP SP2, Windows Server 2003 SP1
and later versions
A named pipes filtering feature was introduced in Windows XP SP2 and Windows Server 2003 SP1.
Named pipes filtering can be dynamically enabled (without requiring a reboot) by adding and setting the
following registry value to 1:
Key: HKLM\SYSTEM\CCS\Services\lanmanserver\Parameters\
Value: PipeFirewallActive (REG_DWORD)
Content: 1 to enable named pipe filtering
The list of allowed named pipes can then be dynamically configured (named pipes can be added or
removed without requiring a reboot) in the following registry value:
Key: HKLM\SYSTEM\CCS\Services\lanmanserver\Parameters\
Value: AllowedPipes (REG_MULTI_SZ)
Content: list of allowed named pipes
When PipeFirewallActive is set to 1 and AllowedPipes is empty, accesses to any named pipe is
refused, both for unauthenticated and authenticated sessions.
Prev Up Next
4.7.7. Named pipes permissions 4.7.9. NULL sessions restrictions
Home
settings in Windows 2000
4.7.9. NULL sessions restrictions settings in Windows 2000
Prev 4.7. NULL sessions Next
Actually, NULL sessions have security implications because the security context of a NULL session contains the
EVERYONE SID. Thus, the EVERYONE group includes anonymous users and, if a DACL allows some accesses for the
EVERYONE group, such accesses can be executed in the context of a NULL session. Microsoft introduced the
AUTHENTICATED USERS group in Windows NT 4.0 SP3, that contains only authenticated users. This group can be used to
grant permissions instead of EVERYONE.
Also, starting with Windows NT 4.0 SP3, the LSA (Local Security Authority) can be configured to restrict the capabilities of a
NULL session, with the following registry value:
Key: HKLM\SYSTEM\CurrentControlSet\Control\LSA\
Value: RestrictAnonymous
Content: 0 (no restriction), 1 (some restrictions), 2 (only valid in Windows 2000)
This registry value is also a group policy security option, starting with Windows 2000:
Setting RestrictAnonymous to 2 completely disables NULL sessions, by removing the EVERYONE SID from the token of a
NULL session.
When RestrictAnonymous is set to 1 in Windows NT or Windows 2000, it is still possible to gather some interesting
information anonymously [48], using the appropriate functions calls and tools [49].
Prev Up Next
4.7.8. Named pipes firewall in Windows XP 4.7.10. NULL sessions restrictions settings in
SP2, Windows Server 2003 SP1 and later Home Windows XP and Windows Server 2003
versions
4.7.10. NULL sessions restrictions settings in Windows XP and Windows Server 2003
Prev 4.7. NULL sessions Next
Starting with Windows XP, EVERYONE does not contain ANONYMOUS LOGON, because the
following security option, which sets the EveryoneIncludesAnonymous registry value, is disabled by
default:
As a consequence, when permissions must allow anonymous accesses, they explicitely grant access to
ANONYMOUS LOGON.
The RestrictAnonymous registry value still exists in Windows XP and Windows Server 2003 and
corresponds to the following security option:
Network access: Do not allow anonymous enumeration of SAM accounts and shares
(Disabled by default)
Given that this security option can either be disabled or enabled, it is easy to deduce that the only valid
values for the RestrictAnonymous registry value in Windows XP and Windows Server 2003 are 0 or 1
(2 is not supported, contrary to Windows 2000).
Prev Up Next
4.7.9. NULL sessions restrictions 4.7.11. NULL session restrictions for
settings in Windows 2000 Home the samr interface in Windows XP and
Windows Server 2003
4.7.11. NULL session restrictions for the samr interface in Windows XP and Windows Server
2003
Prev 4.7. NULL sessions Next
4.7.11. NULL session restrictions for the samr interface in Windows XP and
Windows Server 2003
Windows XP and Windows Server 2003 (systems that are not Active Directory domain controllers) have
one security option that can be used to either block (by default) or allow all anonymous bind to the samr
interface:
This security option sets or unsets the RestrictAnonymousSam registry value to 1. Because this option
is set by default on Windows XP and Windows Server 2003, it is not possible to connect anonymously
to the SAM server on Windows XP and Windows Server 2003 (except for Windows Server 2003
domain controllers).
Prev Up Next
4.7.10. NULL sessions restrictions 4.7.12. NULL session restrictions for
settings in Windows XP and Windows Home the lsarpc interface in Windows XP and
Server 2003 Windows Server 2003
4.7.12. NULL session restrictions for the lsarpc interface in Windows XP and Windows Server
2003
Prev 4.7. NULL sessions Next
4.7.12. NULL session restrictions for the lsarpc interface in Windows XP and
Windows Server 2003
Windows XP and Windows Server 2003 have one security option (enabled by default) that disables or
enables the anonymous translation of SID to name:
When the first security option is enabled, the DACL on the LSA policy object is modified, as shown
with the lsaacl tool [50]:
● When the option is disabled, an ACE explicitly denies the Lookup Names access for the
ANONYMOUS LOGON SID
● When it is set, this ACE is modified, to allow the View Local Info and Lookup Names accesses
for the ANONYMOUS LOGON SID.
In Windows XP, anonymous connections to the lsarpc interface are allowed by default but because the
aforementionned option is disabled by default, it it not possible to translate anonymously SID to name.
On Windows Server 2003 systems that are not Active Directory domain controllers, anonymous
connections to the lsarpc interface are forbidden by default.
In practice, all calls to LsarOpenPolicy or LsarOpenPolicy2 operations fail on non-DC Windows Server
2003 systems.
Thus, the value of the aforementionned option (disabled or enabled) typically does not matter on non-
DC Windows Server 2003 systems, except if the TurnOffAnonymousBlock registry value was
explictly added and set to 1.
Prev Up Next
4.7.11. NULL session restrictions for 4.7.13. NULL sessions restrictions for
the samr interface in Windows XP and Home the samr interface on Active Directory
Windows Server 2003 domain contollers
4.7.13. NULL sessions restrictions for the samr interface on Active Directory domain contollers
Prev 4.7. NULL sessions Next
4.7.13. NULL sessions restrictions for the samr interface on Active Directory
domain contollers
On Active Directory domain controllers, NULL sessions restrictions for the samr interface are based on
members of the Pre-Windows 2000 Compatible Access group, because this group is used in DACL of
Active Directory objects.
Because of the default setting proposed by dcpromo.exe, this group typically contains:
As a consequence, anonymous accesses to the samr interface are typically possible on Active Directory
domain controllers, including full enumeration of accounts stored in AD.
Prev Up Next
4.7.12. NULL session restrictions for 4.7.14. NULL sessions restrictions for
the lsarpc interface in Windows XP and Home the lsarpc interface on Active Directory
Windows Server 2003 domain contollers
4.7.14. NULL sessions restrictions for the lsarpc interface on Active Directory domain contollers
Prev 4.7. NULL sessions Next
On both Windows 2000 and Windows Server 2003 Active Directory domain controllers, it is possible to
connect anonymously to the lsarpc interface.
In Windows Server 2003, this is because the TurnOffAnonymousBlock registry value is added and set
to 1 when a Windows Server 2003 server is promoted to an Active Directory domain controller.
Note: the modification of the TurnOffAnonymousBlock registry value in Windows Server 2003 does
not require a reboot.
On Windows 2000 servers (including Active Directory domain controllers), anonymous translation of
SID to name is allowed, even if the RestrictAnonymous registry value is set to 1.
On Windows Server 2003 servers (including Active Directory domain controllers), the following
security option
Prev Up Next
4.7.13. NULL sessions restrictions for 4.7.15. NULL sessions restrictions of
the samr interface on Active Directory Home server and workstation RPC operations
domain contollers
4.7.15. NULL sessions restrictions of server and workstation RPC operations
Prev 4.7. NULL sessions Next
For some of the lanmanserver and lanmanworkstation RPC services operations (srvsvc and wkssvc
named pipes), restrictions are hardcoded and documented in MSDN, under the Security requirements
section. Sometimes, depending on the requested information level, it is necessary (or not) to be a
member of the Administrators or Account Operators local group.
In addition, on Windows 2000 workstation and member servers, the following srvsvc operations can be
used anonymously if RestrictAnonymous is set to 0:
It is possible to modify the security requirements for some of the srvsvc operations, modifying some of
the security descriptors found under the DefaultSecurity registry key, under the lanmanserver registry
key.
On a default Windows 2000 system, the following registry values are available:
● SrvsvcConfigInfo
● SrvsvcFile
● SrvsvcServerDiskEnum
● SrvsvcSessionInfo
● SrvsvcShareAdminConnect
● SrvsvcShareAdminInfo
● SrvsvcShareConnect
● SrvsvcShareFileInfo
● SrvsvcSharePrintInfo
● SrvsvcStatisticsInfo
● SrvsvcConnection
● SrvsvcTransportEnum
The Tweak UI tool (part of Microsoft PowerToys for Windows XP) has an Access Control feature that
allows the configuration of these security descriptors for Windows XP and Windows Server 2003:
Using Tweak UI, it is possible to harden Windows XP and Windows Server 2003 against NULL
sessions to the srvsvc interface, removing ACE that contain ANONYMOUS LOGON.
The security descriptors are only read when the lanmanserver service starts. Thus, any modification
requires a restart of the service.
Prev Up Next
4.7.14. NULL sessions restrictions for 4.8. MSRPC over TCP/IP
the lsarpc interface on Active Directory Home
domain contollers
4.8. MSRPC over TCP/IP
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.7.15. NULL sessions restrictions of 4.8.1. Portmapper RPC service
Home
server and workstation RPC operations
4.8.1. Portmapper RPC service
Prev 4.8. MSRPC over TCP/IP Next
TCP/IP RPC services listen on dynamic TCP or UDP ports. Thus, to reach a given RPC service,
identified by its interface identifier (UUID), a port mapping service is necessary.
Typically, to discover the port on which a given RPC service can be reached, a client will establish a
TCP connection to port 135, asking for the port allocated to a given RPC service. Then, the client closes
the connection to port 135 and opens a new connection to the port returned by the portmapper service.
To register itself in the endpoint database maintained by the portmapper service, a service calls the
RpcEpRegister() function.
By default, TCP/IP ports for RPC services are allocated in the range of dynamic ports, which starts at
1025. This explains why on most Windows systems, ports immediately higher than 1024 are used by
RPC services. It is possible to configure a specific ports range for RPC services, using the rpccfg tool, as
described in another document [68].
To query the portmapper service, it is possible to use a tool typically named rpcdump. Microsoft
resource kit contains a Windows version of rpcdump. There is also a Windows version in Todd Sabin's
RPC Tools [37], whereas Dave Aitel's SPIKE toolkit contains dcedump [69], a version running on Unix.
Using ifids on one of the portmapper RPC service endpoints, it appears that different RPC interfaces are
supported on a Windows 2000 machine:
These RPC interface identifiers are classified and explained in the next sections.
Prev Up Next
4.8. MSRPC over TCP/IP 4.8.2. RPC interfaces supported by the
Home
rpcss service
4.8.2. RPC interfaces supported by the rpcss service
Prev 4.8. MSRPC over TCP/IP Next
Note: names and purposes of some of the interfaces described in the three following sections have been
documented by Microsoft France technical departments.
The first RPC interface is the DCE RPC endpoint portmapper interface [70]:
The second RPC interface is used by local processes to reach the local endpoint mapper:
Starting with Windows XP, a new RPC interface is available, DbgIdl, to help debugging of RPC
services:
The dbgrpc.exe program, available in the Microsoft Debugging tools package, can then be used, either
locally or remotely to debug RPC services. More information about the usage of dbgrpc.exe is available
in the RPC Debugging section of the Microsoft Debugging Tools package documentation [72].
[...]
64fe0b7f-9ef5-4553-a7db-9a1975777554 v1.0
Prev Up Next
4.8.1. Portmapper RPC service 4.8.3. DCOM-related RPC interfaces
Home
running in the rpcss service
4.8.3. DCOM-related RPC interfaces running in the rpcss service
Prev 4.8. MSRPC over TCP/IP Next
The rpcss service not only runs the RPC subsystem but also the COM Service Control Manager (SCM),
which is at the core of the COM/DCOM infrastructure. As a result, some RPC services are available in the
rpcss service, as well as some ORPC services, as explained in the next section.
The IRemoteActivation (IActivation) interface is an RPC interface implemented by the COM SCM (Services
Control Manager) to handle COM objects activation requests :
The IRemoteActivation RPC interface has exactly one operation, RemoteActivation(), as described in
section 6.2 of the DCOM specification Section 4.18, “DCOM”.
Starting with Windows 2000, the ISystemActivator COM interface is used instead of the
IRemoteActivation RPC interface.
The IOXIDResolver RPC interface (formerly known as IObjectExporter) is remotely used to reach the local
object resolver (OR). The Object Resolver component is in charge to:
● return protocol sequences, string bindings and machine id for an object server, given its OXID
(ResolveOXID() and ResolveOXID2() (only supported by DCOM version 5.2 and above))
● respond to ping requests (SimplePing() and ComplexPing() functions)
● respond to ServerAlive() and ServerAlive2() functions requests
For more information about the DCOM transport into DCE RPC, see [73].
The ISCM RPC interface is a local interface used by local applications to communicate with the local COM
SCM:
The IROT RPC interface is used by local processes to access the Running Object Table (ROT), to register or
unregister COM objects:
b9e79e60-3d52-11ce-aaa1-00006901293f v0.2:IROT
The IMachineActivatorControl is also a local interface used to notify the COM SCM when COM surrogates
start or stop:
Prev Up Next
4.8.2. RPC interfaces supported by the 4.8.4. ORPC interfaces running in the
Home
rpcss service rpcss service
4.8.4. ORPC interfaces running in the rpcss service
Prev 4.8. MSRPC over TCP/IP Next
ORPC (Object RPC) services are used by DCOM (Distributed COM). ORPC calls can be distinguished
from RPC calls because, on the wire, they always have an implicit parameter, either of type ORPCTHIS
or ORPCTHAT (see section 3.2 of Section 4.18, “DCOM”).
Also, versions of ORPC services interface identifiers is always 0.0, as explained in [73] :
Finally, the interface version number (named if_vers) must always be 0.0. This is because
a COM interface may never be modified after it is published. COM interfaces are not
versioned; a new interface is defined instead.
ISCMActivator is an ORPC interface implemented by the COM SCM to handle remote activation
requests (CoCreateInstance(), CoGetClassObject() ...) :
Operation
Interface Operation name
number
000001a0-0000-0000-c000-
000000000046 v0.0: ISystemActivator
(IRemoteSCMActivator)
0x00 QueryInterfaceIRemoteSCMActivator
0x01 AddRefIRemoteISCMActivator
0x02 ReleaseIRemoteISCMActivator
0x03 RemoteGetClassObject
0x04 RemoteCreateInstance
Prev Up Next
4.8.3. DCOM-related RPC interfaces 4.9. Windows core MSRPC interfaces
Home
running in the rpcss service
4.9. Windows core MSRPC interfaces
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Windows NT and Active Directory domains are built on the following MSRPC interfaces:
● Section 4.9.1, “lsarpc interface”: Local Security Authority (LSA) RPC service
● Section 4.9.2, “samr interface”: Security Account Manager RPC service
● Section 4.9.3, “netlogon interface”: Netlogon RPC service
● Section 4.9.4, “drsuapi interface”: Active Directory replication service
● Section 4.9.5, “dssetup interface”: Active Directory setup
Remote administration of Windows services is implemented using the following MSRPC interfaces:
Prev Up Next
4.8.4. ORPC interfaces running in the 4.9.1. lsarpc interface
Home
rpcss service
4.9.1. lsarpc interface
Prev 4.9. Windows core MSRPC interfaces Next
The lsarpc interface is used to communicate with the LSA (Local Security Authority) subsystem.
Before Windows 2000, the lsarpc interface is only available on the lsarpc named pipe endpoint:
Interfaces: 4
12345778-1234-abcd-ef00-0123456789ab v0.0
[...]
In Active Directory domains (and particularly, Active Directory domain controllers) and Windows Server
2003 systems, the lsarpc interface is also available (and used) over a TCP endpoint:
Interfaces: 12
12345778-1234-abcd-ef00-0123456789ab v0.0
[...]
Starting with Windows Server 2003 SP1, some operations of the lsarpc interface can only be used over a
specific protocol sequence.
IDL (Interface Definition Language) for the lsarpc interface is available in Samba 4 [53].
Operation
Interface Operation name Windows API
number
12345778-
1234-abcd-
ef00-
0123456789ab
v0.0: lsarpc
0x00 LsarClose LsaClose
0x01 LsarDelete
0x02 LsarEnumeratePrivileges
0x03 LsarQuerySecurityObject
0x04 LsarSetSecurityObject
0x05 LsarChangePassword
0x06 LsarOpenPolicy LsaOpenPolicy
0x07 LsarQueryInformationPolicy LsaQueryInformationPolicy
0x08 LsarSetInformationPolicy LsaSetInformationPolicy
0x09 LsarClearAuditLog
0x0a LsarCreateAccount
0x0b LsarEnumerateAccounts
0x0c LsarCreateTrustedDomain
0x0d LsarEnumerateTrustedDomains
0x0e LsarLookupNames LsaLookupNames
0x0f LsarLookupSids LsaLookupSids
0x10 LsarCreateSecret
0x11 LsarOpenAccount
0x12 LsarEnumeratePrivilegesAccount LsaEnumerateAccountRights
0x13 LsarAddPrivilegesToAccount LsaAddAccountRights
0x14 LsarRemovePrivilegesFromAccount LsaRemoveAccountRights
0x15 LsarGetQuotasForAccount
0x16 LsarSetQuotasForAccount
0x17 LsarGetSystemAccessAccount
0x18 LsarSetSystemAccessAccount
0x19 LsarOpenTrustedDomain
0x1a LsarQueryInfoTrustedDomain
0x1b LsarSetInformationTrustedDomain
0x1c LsarOpenSecret
0x1d LsarSetSecret
0x1e LsarQuerySecret
0x1f LsarLookupPrivilegeValue
0x20 LsarLookupPrivilegeName
0x21 LsarLookupPrivilegeDisplayName
0x22 LsarDeleteObject
0x23 LsarEnumerateAccountsWithUserRight
0x24 LsarEnumerateAccountRights
0x25 LsarAddAccountRights
0x26 LsarRemoveAccountRights
0x27 LsarQueryTrustedDomainInfo LsaQueryTrustedDomainInfo
0x28 LsarSetTrustedDomainInfo LsaSetTrustedDomainInformation
> Windows
0x29 LsarDeleteTrustedDomain LsaDeleteTrustedDomain
2000
- 0x2a LsarStorePrivateData LsaStorePrivateData
- 0x2b LsarRetrievePrivateData LsaRetrievePrivateData
- 0x2c LsarOpenPolicy2 LsaOpenPolicy
- 0x2d LsarGetUserName
- 0x2e LsarQueryInformationPolicy2
- 0x2f LsarSetInformationPolicy2
- 0x30 LsarQueryTrustedDomainInfoByName
- 0x31 LsarSetTrustedDomainInfoByName
- 0x32 LsarEnumerateTrustedDomainsEx
- 0x33 LsarCreateTrustedDomainEx
- 0x34 LsarCloseTrustedDomainEx
- 0x35 LsarQueryDomainInformationPolicy LsaQueryDomainInformationPolicy
- 0x36 LsarSetDomainInformationPolicy LsaSetDomainInformationPolicy
- 0x37 LsarOpenTrustedDomainByName
- 0x38 LsarTestCall
- 0x39 LsarLookupSids2 LsaLookupSids
- 0x3a LsarLookupNames2 LsaLookupNames2
- 0x3b LsarCreateTrustedDomainEx2
> Windows
2000 Service 0x3c CredrWrite CredWrite
Pack 3 (SP3)
- 0x3d CredrRead CredRead
- 0x3e CredrEnumerate CredEnumerate
- 0x3f CredrWriteDomainCredentials CredWriteDomainCredentials
- 0x40 CredrReadDomainCredentials CredReadDomainCredentials
- 0x41 CredrDelete CredDelete
- 0x42 CredrGetTargetInfo CredGetTargetInfo
- 0x43 CredrProfileLoaded
- 0x44 LsarLookupNames3
- 0x45 CredrGetSessionTypes CredGetSessionTypes
- 0x46 LsarRegisterAuditEvent
- 0x47 LsarGenAuditEvent
- 0x48 LsarUnregisterAuditEvent
- 0x49 LsarQueryForestTrustInformation
- 0x4a LsarSetForestTrustInformation
- 0x4b CredrRename CredRename
- 0x4c LsarLookupSids3
- 0x4d LsarLookupNames4
- 0x4e LsarOpenPolicySce
> Windows
0x4f LsarAdtRegisterSecurityEventSource
Server 2003
- 0x50 LsarAdtUnregisterSecurityEventSource
- 0x51 LsarAdtReportSecurityEvent
> Windows
0x52 CredrFindBestCredential
Vista
- 0x53 LsarSetAuditPolicy
- 0x54 LsarQueryAuditPolicy
- 0x55 LsarEnumerateAuditPolicy
- 0x56 LsarEnumerateAuditCategories
- 0x57 LsarEnumerateAuditSubCategories
- 0x58 LsarLookupAuditCategoryName
- 0x59 LsarLookupAuditSubCategoryName
- 0x5a LsarSetAuditSecurity
- 0x5b LsarQueryAuditSecurity
- 0x5c CredReadByTokenHandle
- 0x5d CredrRestoreCredentials
- 0x5e CredrBackupCredentials
To obtain a handle to the LSA rpc server, one of the following operations must be used:
● LsarOpenPolicy (0x06)
● LsarOpenPolicy2 (0x2c)
● LsarClose (0x00)
To resolve SID to names and vice-versa, the following operations are supported:
● LsarLookupNames (0x0e)
● LsarLookupSids (0x0f)
● LsarLookupNames2 (0x3a)
● LsarLookupSids2 (0x39)
● LsarLookupNames3 (0x44)
● LsarLookupSids3 (0x4c)
● LsarLookupNames4 (0x4d)
To obtain system names (Se*) of security privileges supported by the LSA, the following operation can be
used:
● LsarEnumeratePrivileges (0x02)
To convert between privileges system names, numeric values and descriptions, the following operations can
be used:
● LsarLookupPrivilegeValue (0x1f)
● LsarLookupPrivilegeName (0x20)
● LsarLookupPrivilegeDisplayName (0x21)
To query or set parameters of the LSA policy, the following operation are supported:
● LsarQueryInformationPolicy (0x07)
● LsarSetInformationPolicy (0x08)
● LsarQueryInformationPolicy2 (0x2e)
● LsarSetInformationPolicy2 (0x2f)
● LsarOpenAccount (0x11)
The following operations can be used with an opened handle returned by the LsarOpenAccount operation:
● LsarEnumeratePrivilegesAccount (0x12)
● LsarAddPrivilegesToAccount (0x13)
● LsarRemovePrivilegesFromAccount (0x14)
● LsarGetQuotasForAccount (0x15)
● LsarSetQuotasForAccount (0x16)
● LsarGetSystemAccessAccount (0x17)
● LsarSetSystemAccessAccount (0x18)
● LsarEnumerateAccountRights (0x24)
● LsarAddAccountRights (0x25)
● LsarRemoveAccountRights (0x26)
● LsarEnumerateTrustedDomains (0x0d)
● LsarEnumerateTrustedDomainsEx (0x32)
● LsarCreateTrustedDomain (0x0c)
● LsarCreateTrustedDomainEx (0x33)
● LsarCreateTrustedDomainEx2 (0x3b)
● LsarOpenTrustedDomain (0x19)
● LsarOpenTrustedDomainByName (0x37)
● LsarQueryTrustedDomainInfo (0x27)
● LsarQueryTrustedDomainInfoByName (0x30)
● LsarSetTrustedDomainInfo (0x28)
● LsarSetTrustedDomainInfoByName (0x31)
● LsarCloseTrustedDomainEx (0x34)
● LsarDeleteTrustedDomain (0x29)
● LsarCreateSecret (0x10)
● LsarOpenSecret (0x1c)
● LsarSetSecret (0x1d)
● LsarQuerySecret (0x1e)
● LsarDelete (0x01)
To get and set ACL on LSA objects, the following operations are available:
● LsarQuerySecurityObject (0x03)
● LsarSetSecurityObject (0x04)
Prev Up Next
4.9. Windows core MSRPC interfaces Home 4.9.2. samr interface
4.9.2. samr interface
Prev 4.9. Windows core MSRPC interfaces Next
The samr interface is used to communicate with the SAM (Security Account Manager) subsystem.
Before Windows 2000, the samr interface is only available on the samr named pipe endpoint:
Interfaces: 4
[...]
12345778-1234-abcd-ef00-0123456789ac v0.0
[...]
In Active Directory domains (and particularly, Active Directory domain controllers), the samr interface
is also available (and used) over a TCP endpoint:
Interfaces: 12
[...]
12345778-1234-abcd-ef00-0123456789ac v0.0
[...]
During Active Directory domain joins, the creation of computer accounts is implemented with samr
operations called on the TCP endpoint of Active Directory domain controllers.
IDL (Interface Definition Language) for the samr interface is available in Samba 4 [55].
To connect to the SAM server, one of the following operations are used:
● SamrConnect (0x00)
● SamrConnect2 (0x39)
● SamrConnect3 (0x3d)
● SamrConnect4 (0x3e)
● SamrConnect5 (0x40)
Then, available domains in the SAM server can be enumerated using the following operation:
● SamrEnumerateDomainsInSamServer (0x06)
The following operation is used to obtain the SID of a domain, given its name:
● SamrLookupDomainInSamServer (0x05)
This operation typically returns the BUILTIN domain (S-1-5-32) and the machine domain (local domain
for a non-domain controller machine, NT 4 or Active Directory domain for a domain controller
machine).
● SamrOpenDomain (0x07)
General information about the opened domain can be obtained or set with the following operations:
● SamrQueryInformationDomain (0x08)
● SamrQueryInformationDomain2 (0x2e)
● SamrSetInformationDomain (0x09)
Once a domain is opened, it is possible to enumerate groups, aliases and users, using the following
operations:
● SamrEnumerateGroupsInDomain (0x0b)
● SamrEnumerateAliasesInDomain (0x0f)
● SamrEnumerateUsersInDomain (0x0d)
RID and names resolution inside an opened domain are implemented by the following operations:
● SamrLookupNamesInDomain (0x11)
● SamrLookupIdsInDomain (0x12)
● SamrGetUserDomainPasswordInformation (0x2c)
● SamrGetDomainPasswordInformation (0x38)
To create a new group, alias or user in the opened domain, the following operations can be used:
● SamrCreateGroupInDomain (0x0a)
● SamrCreateAliasInDomain (0x0e)
● SamrCreateUserInDomain (0x0c)
● SamrCreateUser2InDomain (0x32)
To open an existing group, alias or user in the opened domain, the following operations exist:
● SamrOpenGroup (0x13)
● SamrOpenAlias (0x1b)
● SamrOpenUser (0x22)
To delete an existing group, alias or user in the opened domain, the following operations exist:
● SamrDeleteGroup (0x17)
● SamrDeleteAlias (0x1e)
● SamrDeleteUser (0x23)
To obtain a list of members in groups or aliases, the following operations can be used:
● SamrGetMembersInGroup (0x19)
● SamrGetMembersInAlias (0x21)
To add or remove a member to a group or alias, the following operations are available:
● SamrAddMemberToGroup (0x16)
● SamrAddMemberToAlias (0x1f)
● SamrRemoveMemberFromGroup (0x18)
● SamrRemoveMemberFromAlias (0x20)
For aliases, it is also possible to add or remove multiple members to or from an alias:
● SamrAddMultipleMembersToAlias (0x34)
● SamrRemoveMultipleMembersFromAlias (0x35)
To obtain or set information about a given group or alias, the following operations exist:
● SamrQueryInformationGroup (0x14)
● SamrQueryInformationAlias (0x1c)
● SamrSetInformationGroup (0x15)
● SamrSetInformationAlias (0x1d)
● SamrQueryInformationUser (0x24)
● SamrQueryInformationUser2 (0x2f)
● SamrSetInformationUser (0x25)
● SamrSetInformationUser2 (0x3a)
A list of groups containing a given user can be obtained with the following operation:
● SamrGetGroupsForUser (0x27)
Finally, handles returned by the following operations are supposed to be closed, using the
SamrCloseHandle (0x01) operation:
● SamrConnect (0x00)
● SamrConnect2 (0x39)
● SamrConnect3 (0x3d)
● SamrConnect4 (0x3e)
● SamrConnect5 (0x40)
● SamrOpenDomain (0x07)
● SamrOpenGroup (0x13)
● SamrOpenAlias (0x1b)
● SamrOpenUser (0x22)
● SamrCreateUserInDomain (0x0c)
● SamrCreateUser2InDomain (0x32)
● SamrCreateAliasInDomain (0x0e)
● SamrCreateGroupInDomain (0x0a)
Prev Up Next
4.9.1. lsarpc interface Home 4.9.3. netlogon interface
4.9.3. netlogon interface
Prev 4.9. Windows core MSRPC interfaces Next
The netlogon interface is used to communicate with the netlogon service, that typically run on member
servers and domain controllers.
IDL (Interface Definition Language) for the netlogon interface is available in Samba 4 [56].
Operation
Interface Operation name Windows API
number
12345678-
1234-abcd-
ef00-
01234567cffb
v1.0: netlogon
0x00 NetrLogonUasLogon
0x01 NetrLogonUasLogoff
0x02 NetrLogonSamLogon
0x03 NetrLogonSamLogoff
0x04 NetrServerReqChallenge
0x05 NetrServerAuthenticate
0x06 NetrServerPasswordSet
0x07 NetrDatabaseDeltas
0x08 NetrDatabaseSync
0x09 NetrAccountDeltas
0x0a NetrAccountSync
0x0b NetrGetDCName NetGetDCName
0x0c NetrLogonControl
0x0d NetrGetAnyDCName NetGetAnyDCName
0x0e NetrLogonControl2
0x0f NetrServerAuthenticate2
0x10 NetrDatabaseSync2
0x11 NetrDatabaseRedo
0x12 NetrLogonControl2Ex
0x13 NetrEnumerateTrustedDomains
> Windows
0x14 DsrGetDcName DsGetDCName
2000
- 0x15 NetrLogonDummyRoutine1
- 0x16 NetrLogonSetServiceBits
- 0x17 NetrLogonGetTrustRid
- 0x18 NetrLogonComputeServerDigest
- 0x19 NetrLogonComputeClientDigest
- 0x1a NetrServerAuthenticate3
- 0x1b DsrGetDcNameEx DsGetDCName
- 0x1c DsrGetSiteName DsGetSiteName
- 0x1d NetrLogonGetDomainInfo
- 0x1e NetrServerPasswordSet2
- 0x1f NetrServerPasswordGet
- 0x20 NetrLogonSendToSam
- 0x21 DsrAddressToSiteNamesW DsAddressToSiteNames
- 0x22 DsrGetDcNameEx2 DsGetDCName
- 0x23 NetrLogonGetTimeServiceParentDomain
- 0x24 NetrEnumerateTrustedDomainsEx
- 0x25 DsrAddressToSiteNamesExW DsAddressToSiteNames
- 0x26 DsrGetDcSiteCoverageW DsGetDcSiteCoverage
- 0x27 NetrLogonSamLogonEx
- 0x28 DsrEnumerateDomainTrusts DsEnumerateDomainTrusts
- 0x29 DsrDeregisterDnsHostRecords DsDeregisterDnsHostRecords
- 0x2a NetrServerTrustPasswordsGet
> Windows
XP and
0x2b DsrGetForestTrustInformation DsGetForestTrustInformationW
Windows
Server 2003
- 0x2c NetrGetForestTrustInformation
- 0x2d NetrLogonSamLogonWithFlags
- 0x2e NetrServerGetTrustInfo
Prev Up Next
4.9.2. samr interface Home 4.9.4. drsuapi interface
4.9.4. drsuapi interface
Prev 4.9. Windows core MSRPC interfaces Next
The drsuapi interface is used between Active Directory domain controllers for replication:
IDL (Interface Definition Language) for the drsuapi interface is available in Samba 4 [80].
Ethereal has a dissector for this interface [83]. It is particularly useful when used with the Kerberos decryption feature:
in that case, encrypted operations are dissected.
Prev Up Next
4.9.3. netlogon interface Home 4.9.5. dssetup interface
4.9.5. dssetup interface
Prev 4.9. Windows core MSRPC interfaces Next
The dssetup interface (Directory Services Setup) is used in Active Directory environments. The first
operation, DsRolerGetPrimaryDomainInformation, is used to query the configuration of an Active
Directory domain member system.
IDL (Interface Definition Language) for the dssetup interface is available in Samba 4 [54].
The dssetup interface runs in the LSA on Windows 2000 and later and supports at least one operation:
Operation
Interface Operation name Windows API
number
3919286a-
b10c-11d0-
9ba8-
00c04fd92ef5
v0.0: dssetup
Windows
0x00 DsRolerGetPrimaryDomainInformation DsRoleGetPrimaryDomainInformation
2000 and >
Windows
2000 and
Windows XP 0x01 DsRolerDnsNameToFlatName
(before
MS04-011)
- 0x02 DsRolerDcAsDc
- 0x03 DsRolerDcAsReplica
- 0x04 DsRolerDemoteDc
- 0x05 DsRolerGetDcOperationProgress
- 0x06 DsRolerGetDcOperationResults
- 0x07 DsRolerCancel
- 0x08 DsRolerServerSaveStateForUpgrade
- 0x09 DsRolerUpgradeDownlevelServer
- 0x0a DsRolerAbortDownlevelServerUpgrade
A buffer overflow in a logging function in lsasrv.dll was discovered by eEye [84] on 2004/04/13 and fixed in
the MS04-011 [85] Microsoft security patch. This buffer overflow can be specifically exploited with the
DsRolerUpgradeDownlevelServer operation to gain the SYSTEM privilege, because this specific operation
does not impersonate the security context of the caller (i.e., does not call RpcImpersonateClient()).
This buffer overflow has been exploited by the Sasser worm [86], discovered on 2004/04/30.
Starting with Windows Server 2003, these operations belong to the dsrole interface, which can not be
accessed remotely, as explained below. Only the first operation, DsRolerGetPrimaryDomainInformation,
is available in the dssetup interface.
The MS04-011 security patch also removed all operations of the dssetup interface except the first one
(DsRolerGetPrimaryDomainInformation) on Windows 2000 and Windows XP.
Prev Up Next
4.9.4. drsuapi interface Home 4.9.6. eventlog interface
4.9.6. eventlog interface
Prev 4.9. Windows core MSRPC interfaces Next
IDL (Interface Definition Language) for the eventlog interface is available in Samba 4 [57].
Operation
Interface Operation name Windows API
number
82273fdc-e32a-
18c3-3f78-
827929dc23ea v0.0:
eventlog
0x00 ElfrClearELFW ClearEventLog
0x01 ElfrBackupELFW BackupEventLog
0x02 ElfrCloseEL CloseEventLog
0x03 ElfrDeregisterEventSource DeregisterEventSource
0x04 ElfrNumberOfRecords GetNumberOfEventLogRecords
0x05 ElfrOldestRecord GetOldestEventLogRecord
0x06 ElfrChangeNotify NofifyChangeEventLog
0x07 ElfrOpenELW OpenEventLog
0x08 ElfrRegisterEventSourceW RegisterEventSource
0x09 ElfrOpenBELW OpenBackupEventlog
0x0a ElfrReadELW ReadEventLog
0x0b ElfrReportEventW ReportEvent
0x0c ElfrClearELFA ClearEventLog
0x0d ElfrBackupELFA BackupEventLog
0x0e ElfrOpenELA OpenEventLog
0x0f ElfrRegisterEventSourceA RegisterEventSource
0x10 ElfrOpenBELA OpenBackupEventlog
> Windows 2000 0x11 ElfrReadELA ReadEventLog
- 0x12 ElfrReportEventA ReportEvent
- 0x13 ElfrRegisterClusterSvc
- 0x14 ElfrDeregisterClusterSvc
- 0x15 ElfrWriteClusterEvents
- 0x16 ElfrGetLogInformation GetEventLogInformation
> Windows XP 0x17 ElfrFlushEL
> Windows Server
0x18 ElfrReportEventAndSourceW
2003
Operations in the eventlog interface that take Unicode strings as parameters end with W and operations
that take ASCII strings as parameters end with A.
Opening an eventlog:
● ElfrOpenELW (0x07)
● ElfrOpenELA (0x0e)
● ElfrGetLogInformation (0x16)
● ElfrOpenBELW (0x09)
● ElfrOpenBELA (0x10)
● ElfrNumberOfRecords (0x04)
● ElfrOldestRecord (0x05)
Reading records stored in an opened eventlog, the following operations are used:
● ElfrReadELW (0x0a)
● ElfrReadELA (0x11)
● ElfrBackupELFW (0x01)
● ElfrBackupELFA (0x0d)
● ElfrClearELFW (0x00)
● ElfrClearELFA (0x0c)
● ElfrRegisterEventSourceW (0x08)
● ElfrRegisterEventSourceA (0x0f)
● ElfrReportEventW (0x0b)
● ElfrReportEventA (0x12)
● ElfrFlushEL (0x17)
● ElfrCloseEL (0x02)
Prev Up Next
4.9.5. dssetup interface Home 4.9.7. pnp interface
4.9.7. pnp interface
Prev 4.9. Windows core MSRPC interfaces Next
The Plug and Play service runs one RPC service, pnp:
[...]
8d9f4e40-a03d-11ce-8f69-08003e30051b v1.0
[...]
8d9f4e40-a03d-11ce-8f69-08003e30051b v1.0
Before Windows Vista, the \pipe\ntsvcs named pipe endpoint is usually used to reach the pnp interface.
[...]
In Windows NT 4.0, a similar interface exists with exactly the same interface identifier but in version
0.0 and with fewer operations (thanks to Derek Soeder for providing operations names).
[...]
8d9f4e40-a03d-11ce-8f69-08003e30051b v0.0
Prev Up Next
4.9.6. eventlog interface Home 4.9.8. srvsvc interface
4.9.8. srvsvc interface
Prev 4.9. Windows core MSRPC interfaces Next
IDL (Interface Definition Language) for the srvsvc interface is available in Samba 4 [59].
Operation
Interface Operation name Windows API
number
4b324fc8-1670-01d3-
1278-5a47bf6ee188
v3.0: srvsvc
0x00 NetrCharDevEnum NetCharDevEnum
0x01 NetrCharDevGetInfo NetCharDevGetInfo
0x02 NetrCharDevControl NetCharDevControl
0x03 NetrCharDevQEnum NetCharDevQEnum
0x04 NetrCharDevQGetInfo NetCharDevQGetInfo
0x05 NetrCharDevQSetInfo NetCharDevQSetInfo
0x06 NetrCharDevQPurge NetCharDevQPurge
0x07 NetrCharDevQPurgeSelf NetCharDevQPurgeSelf
0x08 NetrConnectionEnum NetConnectionEnum
0x09 NetrFileEnum NetFileEnum
0x0a NetrFileGetInfo NetFileGetInfo
0x0b NetrFileClose NetFileClose
0x0c NetrSessionEnum NetSessionEnum
0x0d NetrSessionDel NetSessionDel
0x0e NetrShareAdd NetShareAdd
0x0f NetrShareEnum NetShareEnum
0x10 NetrShareGetInfo NetShareGetInfo
0x11 NetrShareSetInfo NetShareSetInfo
0x12 NetrShareDel NetShareDel
0x13 NetrShareDelSticky NetShareDel
0x14 NetrShareCheck NetShareCheck
0x15 NetrServerGetInfo NetServerGetInfo
0x16 NetrServerSetInfo NetServerSetInfo
0x17 NetrServerDiskEnum NetServerDiskEnum
0x18 NetrServerStatisticsGet NetServerStatisticsGet
0x19 NetrServerTransportAdd NetServerTransportAdd
0x1a NetrServerTransportEnum NetServerTransportEnum
0x1b NetrServerTransportDel NetServerTransportDel
0x1c NetrRemoteTOD NetRemoteTOD
0x1d NetrServerSetServiceBits
0x1e NetprPathType NetPathType
0x1f NetprPathCanonicalize
0x20 NetprPathCompare
0x21 NetprNameValidate
0x22 NetprNameCanonicalize
0x23 NetprNameCompare
0x24 NetrShareEnumSticky NetShareEnum
0x25 NetrShareDelStart NetShareDel
0x26 NetrShareDelCommit NetShareDel
0x27 NetrpGetFileSecurity
0x28 NetrpSetFileSecurity
0x29 NetrServerTransportAddEx NetServerTransportAddEx
0x2a NetrServerSetServiceBitsEx
0x2b NetrDfsGetVersion
> Windows 2000 0x2c NetrDfsCreateLocalPartition
- 0x2d NetrDfsDeleteLocalPartition
- 0x2e NetrDfsSetLocalVolumeState
- 0x2f NetrDfsSetServerInfo
- 0x30 NetrDfsCreateExitPoint
- 0x31 NetrDfsDeleteExitPoint
- 0x32 NetrDfsModifyPrefix
- 0x33 NetrDfsFixLocalVolume
- 0x34 NetrDfsManagerReportSiteInfo
> Windows XP and
0x35 NetrServerTransportDelEx NetServerTransportDelEx
Windows Server 2003
> Windows Vista 0x36 NetrServerAliasAdd
0x37 NetrServerAliasEnum
0x38 NetrServerAliasDel
0x39 NetrShareDelEx
● NetrServerGetInfo (0x15)
● NetrServerSetInfo (0x16)
Managing shares:
● NetrShareAdd (0x0e)
● NetrShareEnum (0x0f)
● NetrShareGetInfo (0x10)
● NetrShareSetInfo (0x11)
● NetrShareDel (0x12)
● NetrShareDelSticky (0x13)
● NetrShareCheck (0x14)
● NetrSessionEnum (0x0c)
● NetrSessionDel (0x0d)
● NetrFileEnum (0x09)
● NetrFileGetInfo (0x0a)
● NetrFileClose (0x0b)
● NetrServerTransportAdd (0x19)
● NetrServerTransportEnum (0x1a)
● NetrServerTransportDel (0x1b)
Prev Up Next
4.9.7. pnp interface Home 4.9.9. svcctl interface
4.9.9. svcctl interface
Prev 4.9. Windows core MSRPC interfaces Next
The svcctl interface is used to manage Windows services via the SCM (Service Control Manager).
IDL (Interface Definition Language) for the svcctl interface is available in Samba 4 [60].
Operation
Interface Operation name Windows API
number
367aeb81-9844-35f1-
ad32-98f038001003
v2.0: svcctl
0x00 CloseServiceHandle CloseServiceHandle
0x01 ControlService ControlService
0x02 DeleteService DeleteService
0x03 LockServiceDatabase LockServiceDatabase
0x04 QueryServiceObjectSecurity QueryServiceObjectSecurity
0x05 SetServiceObjectSecurity SetServiceObjectSecurity
0x06 QueryServiceStatus QueryServiceStatus
0x07 SetServiceStatus SetServiceStatus
0x08 UnlockServiceDatabase UnlockServiceDatabase
0x09 NotifyBootConfigStatus NotifyBootConfigStatus
0x0a ScSetServiceBitsW SetServiceBits
0x0b ChangeServiceConfigW ChangeServiceConfig
0x0c CreateServiceW CreateService
0x0d EnumDependentServicesW EnumDependentServices
0x0e EnumServicesStatusW EnumServicesStatus
0x0f OpenSCManagerW OpenSCManager
0x10 OpenServiceW OpenService
0x11 QueryServiceConfigW QueryServiceConfig
0x12 QueryServiceLockStatusW QueryServiceLockStatus
0x13 StartServiceW StartService
0x14 GetServiceDisplayNameW GetServiceDisplayName
0x15 GetServiceKeyNameW GetServiceKeyName
0x16 ScSetServiceBitsA SetServiceBits
0x17 ChangeServiceConfigA ChangeServiceConfig
0x18 CreateServiceA CreateService
0x19 EnumDependentServicesA EnumDependentServices
0x1a EnumServicesStatusA EnumServicesStatus
0x1b OpenSCManagerA OpenSCManager
0x1c OpenServiceA OpenService
0x1d QueryServiceConfigA QueryServiceConfig
0x1e QueryServiceLockStatusA QueryServiceLockStatus
0x1f StartServiceA StartService
0x20 GetServiceDisplayNameA GetServiceDisplayName
0x21 GetServiceKeyNameA GetServiceKeyName
0x22 ScGetCurrentGroupStateW
0x23 EnumServiceGroupW
0x24 ChangeServiceConfig2A ChangeServiceConfig2
0x25 ChangeServiceConfig2W ChangeServiceConfig2
0x26 QueryServiceConfig2A QueryServiceConfig2
> Windows 2000 0x27 QueryServiceConfig2W QueryServiceConfig2
- 0x28 QueryServiceStatusEx QueryServiceStatusEx
- 0x29 EnumServicesStatusExA EnumServicesStatusEx
- 0x2a EnumServicesStatusExW EnumServicesStatusEx
> Windows XP and
0x2b ScSendTSMessage
Windows Server 2003
> Windows Vista 0x2c CreateServiceWOW64A
0x2d CreateServiceWOW64W
0x2e ScQueryServiceTagInfo
0x2f NotifyServiceStatusChange NotifyServiceStatusChange
0x30 GetNotifyResult NotifyServiceStatusChange
0x31 CloseNotifyHandle NotifyServiceStatusChange
0x32 ControlServiceExA ControlServiceExA
0x33 ControlServiceExW ControlServiceExW
0x34 ScSendPnPMessage
0x35 ScValidatePnPService
0x36 ScOpenServiceStatusHandle NotifyServiceStatusChange
The svcctl interface contains so-called Unicode operations (with names ending with W) and ASCII
operations (with names ending with A).
● OpenSCManagerW (0x0f)
● OpenSCManagerA (0x1b)
● LockServiceDatabase (0x03)
● UnlockServiceDatabase (0x08)
Enumerating services:
● EnumServicesStatusW (0x0e)
● EnumServicesStatusExW (0x2a)
● EnumServicesStatusA (0x1a)
● EnumServicesStatusExA (0x29)
● OpenServiceW (0x10)
● OpenServiceA (0x1c)
Starting a service:
● StartServiceW (0x13)
● StartServiceA (0x1f)
● QueryServiceStatus (0x06)
● QueryServiceStatusEx (0x28)
● SetServiceStatus (0x07)
● ControlService (0x01)
● QueryServiceConfigW (0x11)
● QueryServiceConfigA (0x1d)
● QueryServiceConfig2W (0x27)
● QueryServiceConfig2A (0x26)
● QueryServiceLockStatusW (0x12)
● QueryServiceLockStatusA (0x1e)
● GetServiceDisplayNameW (0x14)
● GetServiceDisplayNameA (0x20)
● GetServiceKeyNameW (0x15)
● GetServiceKeyNameA (0x21)
● ChangeServiceConfigW (0x0b)
● ChangeServiceConfigA (0x17)
● ChangeServiceConfig2W (0x25)
● ChangeServiceConfig2A (0x24)
● QueryServiceObjectSecurity (0x04)
● SetServiceObjectSecurity (0x05)
● CreateServiceW (0x0c)
● CreateServiceA (0x18)
Removing a service:
● DeleteService (0x02)
● EnumDependentServicesW (0x0d)
● EnumDependentServicesA (0x19)
● EnumServiceGroupW (0x23)
● CloseServiceHandle (0x00)
Prev Up Next
4.9.8. srvsvc interface Home 4.9.10. winreg interface
4.9.10. winreg interface
Prev 4.9. Windows core MSRPC interfaces Next
The winreg interface is used to access to the registry, either locally or remotely. The interface also
contains 3 operations related to systems shutdown.
IDL (Interface Definition Language) for the winreg interface is available in Samba 4 [61].
Operation
Interface Operation name Windows API
number
338cd001-2244-31f1-
aaaa-900038001003
v1.0: winreg
0x00 OpenClassesRoot RegConnectRegistry
0x01 OpenCurrentUser RegConnectRegistry
0x02 OpenLocalMachine RegConnectRegistry
0x03 OpenPerformanceData RegConnectRegistry
0x04 OpenUsers RegConnectRegistry
0x05 BaseRegCloseKey RegCloseKey
0x06 BaseRegCreateKey RegCreateKeyEx
0x07 BaseRegDeleteKey RegDeleteKeyEx
0x08 BaseRegDeleteValue RegDeleteValue
0x09 BaseRegEnumKey RegEnumKeyEx
0x0a BaseRegEnumValue RegEnumValue
0x0b BaseRegFlushKey RegFlushKey
0x0c BaseRegGetKeySecurity RegGetKeySecurity
0x0d BaseRegLoadKey RegLoadKey
0x0e BaseRegNotifyChangeKeyValue RegNotifyChangeKeyValue
0x0f BaseRegOpenKey RegOpenKeyEx
0x10 BaseRegQueryInfoKey RegQueryInfoKey
0x11 BaseRegQueryValue RegQueryValueEx
0x12 BaseRegReplaceKey RegReplaceKey
0x13 BaseRegRestoreKey RegRestoreKey
0x14 BaseRegSaveKey RegSaveKey
0x15 BaseRegSetKeySecurity RegSetKeySecurity
> Windows 2000 0x16 BaseRegSetValue RegSetValueEx
- 0x17 BaseRegUnLoadKey RegUnloadKey
- 0x18 BaseInitiateSystemShutdown InitiateSystemShutdown
- 0x19 BaseAbortSystemShutdown AbortSystemShutdown
- 0x1a BaseRegGetVersion
- 0x1b OpenCurrentConfig
- 0x1c OpenDynData
- 0x1d BaseRegQueryMultipleValues RegQueryMultipleValues
- 0x1e BaseInitiateSystemShutdownEx InitiateSystemShutdownEx
> Windows XP and
Windows Server 0x1f BaseRegSaveKeyEx RegSaveKeyEx
2003
- 0x20 OpenPerformanceText
- 0x21 OpenPerformanceNlsText
> Windows Server
0x22 BaseRegQueryMultipleValues2
2003 SP1
- 0x23 BaseRegDeleteKeyEx RegDeleteKeyEx
Prev Up Next
4.9.9. svcctl interface Home 4.9.11. wkssvc interface
4.9.11. wkssvc interface
Prev 4.9. Windows core MSRPC interfaces Next
IDL (Interface Definition Language) for the wkssvc interface is available in Samba 4 [62].
Operation
Interface Operation name Windows API
number
6bffd098-
a112-3610-
9833-
46c3f87e345a
v1.0: wkssvc
0x00 NetrWkstaGetInfo NetWkstaGetInfo
0x01 NetrWkstaSetInfo NetWkstaSetInfo
0x02 NetrWkstaUserEnum NetWkstaUserEnum
0x03 NetrWkstaUserGetInfo NetWkstaUserGetInfo
0x04 NetrWkstaUserSetInfo NetWkstaUserSetInfo
0x05 NetrWkstaTransportEnum NetWkstaTransportEnum
0x06 NetrWkstaTransportAdd NetWkstaTransportAdd
0x07 NetrWkstaTransportDel NetWkstaTransportDel
0x08 NetrUseAdd NetUseAdd
0x09 NetrUseGetInfo NetUseGetInfo
0x0a NetrUseDel NetUseDel
0x0b NetrUseEnum NetUseEnum
0x0c NetrMessageBufferSend NetMessageBufferSend
0x0d NetrWorkstationStatisticsGet NetWkstaStatisticsGet
0x0e NetrLogonDomainNameAdd
> Windows
0x0f NetrLogonDomainNameDel
2000
- 0x10 NetrJoinDomain NetJoinDomain
- 0x11 NetrUnjoinDomain NetUnjoinDomain
- 0x12 NetrValidateName NetValidateName
- 0x13 NetrRenameMachineInDomain NetRenameMachineInDomain
- 0x14 NetrGetJoinInformation NetGetJoinInformation
- 0x15 NetrGetJoinableOUs NetGetJoinableOUs
- 0x16 NetrJoinDomain2 NetJoinDomain
- 0x17 NetrUnjoinDomain2 NetUnjoinDomain
- 0x18 NetrRenameMachineInDomain2 NetRenameMachineInDomain
- 0x19 NetrValidateName2 NetValidateName
- 0x1a NetrGetJoinableOUs2 NetGetJoinableOUs
> Windows
XP and
0x1b NetrAddAlternateComputerName NetAddAlternateComputerName
Windows
Server 2003
- 0x1c NetrRemoveAlternateComputerName NetRemoveAlternateComputerName
- 0x1d NetrSetPrimaryComputerName NetSetPrimaryComputerName
- 0x1e NetrEnumerateComputerNames NetEnumerateComputerNames
- 0x1f NetrWorkstationResetDfsCache
A vulnerability in the workstation service was discovered by Yuji Ukai [64] and fixed by Microsoft in
November 2003 in the MS03-049 security bulletin [65]. It can be exploited anonymously because it is
always possible to open the wkssvc named pipe in the context of a NULL session, as explained earlier.
● NetrWkstaGetInfo (0x00)
● NetrWkstaSetInfo (0x01)
● NetrUseEnum (0x0b)
● NetrUseGetInfo (0x09)
● NetrUseAdd (0x08)
● NetrUseDel (0x0a)
● NetrWkstaTransportEnum (0x05)
● NetrWkstaTransportAdd (0x06)
● NetrWkstaTransportDel (0x07)
● NetrGetJoinInformation (0x14)
● NetrGetJoinableOUs (0x15)
● NetrGetJoinableOUs2 (0x1a)
● NetrJoinDomain (0x10)
● NetrJoinDomain2 (0x16)
● NetrUnjoinDomain (0x11)
● NetrUnjoinDomain2 (0x17)
● NetrAddAlternateComputerName (0x1b)
● NetrRemoveAlternateComputerName (0x1c)
● NetrSetPrimaryComputerName (0x1d)
● NetrEnumerateComputerNames (0x1e)
Prev Up Next
4.9.10. winreg interface 4.10. Windows services MSRPC
Home
interfaces
4.10. Windows services MSRPC interfaces
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.9.11. wkssvc interface 4.10.1. Active Directory domain
Home
controllers RPC services
4.10.1. Active Directory domain controllers RPC services
Prev 4.10. Windows services MSRPC interfaces Next
The following RPC interfaces are supported on a Windows 2000 domain controller to handle backup and restore
of Active Directory:
By default, these RPC services are registered in the endpoint mapper database on a dynamic TCP port. However,
it is possible to set a registry value to configure these services to listen on a fixed port [87]. Once this value is
configured, the portmapper service will always return this fixed port when asked for one of these interfaces.
Windows Server 2003 and later versions support the dsrole interface, available on the following endpoint:
[...]
1cbcad78-df0b-4934-b558-87839ea501c9 v0.0
[...]
There is another interface in the ntdsa.dll DLL, which contains only two operations:
Table 4.30. dsaop operations
Prev Up Next
4.10. Windows services MSRPC interfaces Home 4.10.2. Computer Browser service
4.10.2. Computer Browser service
Prev 4.10. Windows services MSRPC interfaces Next
Prev Up Next
4.10.1. Active Directory domain 4.10.3. DCOM Server Process Launcher
Home
controllers RPC services
4.10.3. DCOM Server Process Launcher
Prev 4.10. Windows services MSRPC interfaces Next
Prev Up Next
4.10.2. Computer Browser service Home 4.10.4. Distributed File System service
4.10.4. Distributed File System service
Prev 4.10. Windows services MSRPC interfaces Next
IDL (Interface Definition Language) for the netdfs interface is available in Samba 4 [58].
Operation
Interface Operation name Windows API
number
4fc742e0-4a10-11cf-
8273-00aa004ae673
v3.0: netdfs
0x00 NetrDfsManagerGetVersion
0x01 NetrDfsAdd NetDfsAdd
0x02 NetrDfsRemove NetDfsRemove
0x03 NetrDfsSetInfo NetDfsSetInfo
0x04 NetrDfsGetInfo NetDfsGetInfo
0x05 NetrDfsEnum NetDfsEnum
0x06 NetrDfsRename
0x07 NetrDfsMove NetDfsMove
0x08 NetrDfsManagerGetConfigInfo
0x09 NetrDfsManagerSendSiteInfo
0x0a NetrDfsAddFtRoot NetDfsAddFtRoot
0x0b NetrDfsRemoveFtRoot NetDfsRemoveFtRoot
0x0c NetrDfsAddStdRoot NetDfsAddStdRoot
0x0d NetrDfsRemoveStdRoot NetDfsRemoveStdRoot
0x0e NetrDfsManagerInitialize NetDfsManagerInitialize
0x0f NetrDfsAddStdRootForced NetDfsAddStdRootForced
0x10 NetrDfsGetDcAddress
0x11 NetrDfsSetDcAddress
0x12 NetrDfsFlushFtTable
0x13 NetrDfsAdd2
0x14 NetrDfsRemove2
0x15 NetrDfsEnumEx
0x16 NetrDfsSetInfo2
Prev Up Next
4.10.3. DCOM Server Process Launcher Home 4.10.5. DNS server
4.10.5. DNS server
Prev 4.10. Windows services MSRPC interfaces Next
Windows DNS server (dns.exe process) runs one RPC service, listening on the following endpoints:
It is possible to configure the RPC transports of the RPC service run by the DNS Server, using the
RpcProtocol registry value, documented in Microsoft DNS Server Registry Parameters, Part 1 of 3:
Key: HKLM\SYSTEM\CCS\Services\DNS\Parameters\
Value: RpcProtocol (REG_DWORD)
Default value: 0xFFFFFFFF (all protocols enabled)
Prev Up Next
4.10.4. Distributed File System service Home 4.10.6. Exchange RPC services
4.10.6. Exchange RPC services
Prev 4.10. Windows services MSRPC interfaces Next
The MAPI interface (also known as Exchange Server Store EMSMDB Interface) is identified as
follows:
a4f1db00-ca47-1067-b31f-00dd010662da v0.81
[88] lists identifiers of Exchange RPC interfaces exposed when the Secure Mail Publishing feature of
ISA Server 2000 is used.
The following interface identifiers are registered in the endpoint mapper database of an Exchange 2000
server:
Prev Up Next
4.10.5. DNS server 4.10.7. Exchange RPC services in
Home
Active Directory domains
4.10.7. Exchange RPC services in Active Directory domains
Prev 4.10. Windows services MSRPC interfaces Next
Active Directory domain controllers that have the Global Catalog server roles register the following RPC services,
which are used by MAPI clients to access the Directory Service that was previously integrated in Exchange before
Exchange 2000:
NSPI operations offered by an Global Catalog Active Directory domain controller are either called directly (Outlook
2000 and later MAPI clients) or through a proxy run by the Exchange server, as described in [89].
An Exchange server integrated in an Active Directory domain registers the NSPI interface, to proxy NSPI requests to
Global Catalog Active Directory domain controllers:
The rxds interface is also registered on an Exchange 2000 server but is not registered in the endpoint mapper:
f5cc5a7c-4264-101a-8c59-08002b2f8426 v21.0
Prev Up Next
4.10.6. Exchange RPC services Home 4.10.8. File Replication service
4.10.8. File Replication service
Prev 4.10. Windows services MSRPC interfaces Next
The File Replication Service (ntfrs.exe process) runs 3 RPC services on one TCP port:
f5cc59b4-4264-101a-8c59-08002b2f8426 v1.1
d049b186-814f-11d1-9a3c-00c04fc9b232 v1.1
a00c021c-2be2-11d2-b678-0000f87a8f8e v1.0
Prev Up Next
4.10.7. Exchange RPC services in 4.10.9. IIS services
Home
Active Directory domains
4.10.9. IIS services
Prev 4.10. Windows services MSRPC interfaces Next
In Windows 2000, IIS (Internet Information Server) 5 services (HTTP, SMTP, FTP, NNTP) run in a
single process, inetinfo.exe.
The inetinfo.exe (IIS 5) process runs RPC services on the following endpoints:
8cfb5d70-31a4-11cf-a7d8-00805f48a135 v3.0
4f82f460-0e21-11cf-909e-00805f48a135 v4.0
The IMAP4 service (imap4svc.dll), installed by Exchange, runs the following RPC service:
2465e9e0-a873-11d0-930b-00a0c90ab17c v3.0
The POP3 service (pop3svc.dll), installed by Exchange, runs the following RPC service:
1be617c0-31a5-11cf-a7d8-00805f48a135 v3.0
The following interface identifiers correspond to the GUID of the COM components activated to handle
IIS management :
The Inter-site Messaging service (ismserv.exe process) runs one RPC service, available on the following
endpoints:
The following RPC service runs in the ismip.dll DLL, loaded in the ismserv.exe process context:
Prev Up Next
4.10.9. IIS services 4.10.11. Message Queuing and Distributed
Home
Transaction Coordinator services
4.10.11. Message Queuing and Distributed Transaction Coordinator services
Prev 4.10. Windows services MSRPC interfaces Next
The Message Queuing service (msmq) runs RPC services, listening on the ncacn_ip_tcp transport. By
default, the msmq services opens 4 TCP ports [81], including one or several of 2101/tcp, 2103/tcp, 2105/
tcp and 2107/tcp.
The mqqm.dll (Windows NT MQ Queue Manager) DLL, loaded in the mqsvc.exe process, contains the
following RPC services:
fdb3a030-065f-11d1-bb9b-00a024ea5525 v1.0
76d12b80-3467-11d3-91ff-0090272f9ea3 v1.0
1088a980-eae5-11d0-8d9b-00a02453c337 v1.0
5b5b3580-b0e0-11d1-b92d-0060081e87f0 v1.0
41208ee0-e970-11d1-9b9e-00e02c064c39 v1.0
A vulnerability in the QMDeleteObject operation was discovered by Kostya Kortchinsky and fixed by
the MS05-017 security bulletin [82] in April 2005.
906b0ce0-c70b-1067-b317-00dd010662da v1.0
This RPC service also runs in the Distributed Transaction Coordinator service process (msdtc.exe),
which opens a dynamic port, as well as TCP port 3372 (at least on Windows 2000)
Prev Up Next
4.10.10. Inter-site Messaging service Home 4.10.12. Messenger service
4.10.12. Messenger service
Prev 4.10. Windows services MSRPC interfaces Next
The messenger service runs two RPC services, available on two endpoints:
The MS03-043 Microsoft security bulletin removed support for the msgsvcsend interface and for the
UDP endpoint, leaving only the msgsvc named pipe.
Because the Messenger service is running in a shared process, removing the UDP endpoint was an
important security improvement because before, the ncadg_ip_udp transport could be used with this
endpoint to reach anonymously other RPC services running in the same process.
Windows XP SP2 and Windows Server 2003 SP1 do not support the msgsvcsend interface and thus do
not have the UDP endpoint. In addition, the Messenger service is disabled by default on Windows
Server 2003 (all versions) and Windows XP SP2.
[...]
17fdd703-1827-4e34-79d4-24a55c53bb37 v1.0
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc v1.0
[...]
17fdd703-1827-4e34-79d4-24a55c53bb37 v1.0
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc v1.0
The UDP transport is frequently used with the msgsvcsend interface to massively send popup windows
containing advertisement messages [77].
The two RPC services run by the messenger service have the following interfaces identifiers:
The msgsvc interface supports 4 operations that manipulate NetBIOS names on a local or remote
system:
The msgsvcsend interface supports one operation, to send a message to a registered NetBIOS name
using MSRPC:
The msgsvcsend interface is frequently used to send advertisement messages, using the
NetrSendMessage operation.
The MS03-043 [78] Microsoft security bulletin includes a patch that completely removes support for the
msgsvcsend interface of the Messenger service (both server-side function in msgsvc.dll and client-side
function in wkssvc.dll are removed in patched versions of these two DLL).
Prev Up Next
4.10.11. Message Queuing and 4.10.13. NetDDE service
Distributed Transaction Coordinator Home
services
4.10.13. NetDDE service
Prev 4.10. Windows services MSRPC interfaces Next
Prev Up Next
4.10.12. Messenger service Home 4.10.14. RPC locator service
4.10.14. RPC locator service
Prev 4.10. Windows services MSRPC interfaces Next
The RPC locator service runs one RPC service, available on the following endpoint:
A vulnerability in the locator service was published by David Litchfield in January 2003 [75]. It was
fixed by the MS03-001 Microsoft security patch [76].
As the locator named pipe is one of the named pipe that can be accessed in the context of a NULL
session, this vulnerability can be exploited remotely without any authentication.
Prev Up Next
4.10.13. NetDDE service Home 4.10.15. Scheduler service
4.10.15. Scheduler service
Prev 4.10. Windows services MSRPC interfaces Next
The scheduler service runs RPC services allowing remote configuration of scheduled tasks (AT jobs).
These RPC services are available on two endpoints:
Before Windows XP the Scheduler service was implemented in a single process, mstask.exe. Starting
with Windows XP, the Scheduler service runs in a svchost.exe instance process (schedsvc.dll) and runs
an additional RPC service (the third one in the list below).
[...]
1ff70682-0a51-30e8-076d-740be8cee98b v1.0
378e52b0-c0a9-11cf-822d-00aa0051e40f v1.0
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53 v1.0
[...]
1ff70682-0a51-30e8-076d-740be8cee98b v1.0
378e52b0-c0a9-11cf-822d-00aa0051e40f v1.0
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53 v1.0
X:\>
IDL (Interface Definition Language) for the atsvc interface is available in Samba 4 [79].
Table 4.61. atsvc operations
Enumerating AT jobs:
● NetrJobEnum (0x02)
● NetrJobAdd (0x00)
● NetrJobDel (0x01)
● NetrJobGetInfo (0x03)
Submission of AT jobs is by default restricted to only members of the Administrators group. On domain
controllers, it is possible to also allow members of the Server Operators group to submit AT jobs, by
setting the SubmitControl registry value to 1 (not recommended).
[...]
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53 v1.0
1ff70682-0a51-30e8-076d-740be8cee98b v1.0
378e52b0-c0a9-11cf-822d-00aa0051e40f v1.0
86d35949-83c9-4044-b424-db363231fd0c v1.0
[...]
Prev Up Next
4.10.14. RPC locator service Home 4.10.16. Spooler service
4.10.16. Spooler service
Prev 4.10. Windows services MSRPC interfaces Next
Starting with Windows Server 2003, the Spooler service does not create the spoolss named pipe endpoint by default if
no shared printer is configured. Instead, the spoolss LPC port is used as local endpoint to communicate with the
Spooler service.
It is possible to set the RegisterSpoolerRemoteRpcEndpoint registry value to 1 to force the creation of the spoolss
named pipe endpoint, even if no shared printer is configured:
IDL (Interface Definition Language) for the spoolss interface is available in Samba 4 [66].
Operation
Interface Operation name Windows API
number
12345678-
1234-abcd-
ef00-
0123456789ab
v1.0:
winspool
(spoolss)
0x00 RpcEnumPrinters EnumPrinters
0x01 RpcOpenPrinter OpenPrinter
0x02 RpcSetJob SetJob
0x03 RpcGetJob GetJob
0x04 RpcEnumJobs EnumJobs
0x05 RpcAddPrinter AddPrinter
0x06 RpcDeletePrinter DeletePrinter
0x07 RpcSetPrinter SetPrinter
0x08 RpcGetPrinter GetPrinter
0x09 RpcAddPrinterDriver AddPrinterDriver
0x0a RpcEnumPrinterDrivers EnumPrinterDrivers
0x0b RpcGetPrinterDriver GetPrinterDriver
0x0c RpcGetPrinterDriverDirectory GetPrinterDriverDirectory
0x0d RpcDeletePrinterDriver DeletePrinterDriver
0x0e RpcAddPrintProcessor AddPrintProcessor
0x0f RpcEnumPrintProcessors EnumPrintProcessors
0x10 RpcGetPrintProcessorDirectory GetPrintProcessorDirectory
0x11 RpcStartDocPrinter StartDocPrinter
0x12 RpcStartPagePrinter StartPagePrinter
0x13 RpcWritePrinter WritePrinter
0x14 RpcEndPagePrinter EndPagePrinter
0x15 RpcAbortPrinter AbortPrinter
0x16 RpcReadPrinter ReadPrinter
0x17 RpcEndDocPrinter EndDocPrinter
0x18 RpcAddJob AddJob
0x19 RpcScheduleJob ScheduleJob
0x1a RpcGetPrinterData GetPrinterData
0x1b RpcSetPrinterData SetPrinterData
0x1c RpcWaitForPrinterChange
0x1d RpcClosePrinter ClosePrinter
0x1e RpcAddForm AddForm
0x1f RpcDeleteForm DeleteForm
0x20 RpcGetForm GetForm
0x21 RpcSetForm SetForm
0x22 RpcEnumForms EnumForms
0x23 RpcEnumPorts EnumPorts
0x24 RpcEnumMonitors EnumMonitors
0x25 RpcAddPort AddPort
0x26 RpcConfigurePort ConfigurePort
0x27 RpcDeletePort DeletePort
0x28 RpcCreatePrinterIC
0x29 RpcPlayGdiScriptOnPrinterIC
0x2a RpcDeletePrinterIC
0x2b RpcAddPrinterConnection AddPrinterConnection
0x2c RpcDeletePrinterConnection DeletePrinterConnection
0x2d RpcPrinterMessageBox
0x2e RpcAddMonitor AddMonitor
0x2f RpcDeleteMonitor DeleteMonitor
0x30 RpcDeletePrintProcessor DeletePrintProcessor
0x31 RpcAddPrintProvidor AddPrintProvidor
0x32 RpcDeletePrintProvidor DeletePrintProvidor
0x33 RpcEnumPrintProcessorDatatypes EnumPrintProcessorDatatypes
0x34 RpcResetPrinter ResetPrinter
0x35 RpcGetPrinterDriver2 GetPrinterDriver2
0x36 RpcClientFindFirstPrinterChangeNotification FindFirstPrinterChangeNotification
0x37 RpcFindNextPrinterChangeNotification FindNextPrinterChangeNotification
0x38 RpcFindClosePrinterChangeNotification FindClosePrinterChangeNotification
0x39 RpcRouterFindFirstPrinterChangeNotificationOld
0x3a RpcReplyOpenPrinter
0x3b RpcRouterReplyPrinter
0x3c RpcReplyClosePrinter
0x3d RpcAddPortEx
0x3e RpcRemoteFindFirstPrinterChangeNotification
0x3f RpcSpoolerInit
0x40 RpcResetPrinterEx
0x41 RpcRemoteFindFirstPrinterChangeNotificationEx
0x42 RpcRouterReplyPrinterEx
0x43 RpcRouterRefreshPrinterChangeNotification
0x44 RpcSetAllocFailCount
0x45 RpcSplOpenPrinter
0x46 RpcAddPrinterEx
0x47 RpcSetPort
0x48 RpcEnumPrinterData
0x49 RpcDeletePrinterData
0x4a RpcClusterSplOpen
0x4b RpcClusterSplClose
0x4c RpcClusterSplIsAlive
0x4d RpcSetPrinterDataEx
0x4e RpcGetPrinterDataEx
0x4f RpcEnumPrinterDataEx
0x50 RpcEnumPrinterKey
0x51 RpcDeletePrinterDataEx
0x52 RpcDeletePrinterKey
0x53 RpcSeekPrinter
0x54 RpcDeletePrinterDriverEx
0x55 RpcAddPerMachineConnection
0x56 RpcDeletePerMachineConnection
0x57 RpcEnumPerMachineConnections
0x58 RpcXcvData
0x59 RpcAddPrinterDriverEx
0x5a RpcSplOpenPrinter
0x5b RpcGetSpoolFileInfo
0x5c RpcCommitSpoolData
0x5d RpcCloseSpoolFileHandle
0x5e RpcFlushPrinter FlushPrinter
> Windows
XP and
0x5f RpcSendRecvBidiData
Windows
Server 2003
0x60 RpcAddDriverCatalog
> Windows
0x61 RpcAddPrinterConnection2
Vista
0x62 RpcDeletePrinterConnection2
0x63 RpcInstallPrinterDriverFromPackage
0x64 RpcUploadPrinterDriverPackage
0x65 RpcGetCorePrinterDrivers
0x66 RpcCorePrinterDriverInstalled
0x67 RpcGetPrinterDriverPackagePath
0x68 RpcReportJobProcessingProgress
In August 2005, a security vulnerability discovered by Kostya Kortchinsky was fixed by Microsoft in the MS05-043
security bulletin [67]. The vulnerability can be exploited calling the AddPrinterEx operation (opnum 0x46).
Prev Up Next
4.10.15. Scheduler service Home 4.10.17. WINS service
4.10.17. WINS service
Prev 4.10. Windows services MSRPC interfaces Next
The WINS service (wins.exe process) runs two RPC services, available on two endpoints:
45f52c28-7f9f-101a-b52b-08002b2efabe v1.0
811109bf-a4e1-11d1-ab54-00a0c91e9b45 v1.0
The WINS service also opens a dynamic UDP port, which does not seem to be used by a RPC service.
Prev Up Next
4.10.16. Spooler service Home 4.11. Other MSRPC interfaces
4.11. Other MSRPC interfaces
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.10.17. WINS service Home 4.11.1. Application Management service
4.11.1. Application Management service
Prev 4.11. Other MSRPC interfaces Next
The Application Management service runs one RPC service, available on the following endpoint:
[...]
8c7daf44-b6dc-11d1-9a4c-0020af6e7c57 v1.0
Prev Up Next
4.11. Other MSRPC interfaces Home 4.11.2. Certificate services
4.11.2. Certificate services
Prev 4.11. Other MSRPC interfaces Next
The certificate services runs one RPC service on the following endpoint:
[...]
91ae6020-9e3c-11cf-8d7c-00aa00c091be v0.0
[...]
Excerpt of the How Certificate Services Works section of Windows Server 2003 documentation:
The ICertPassage RPC protocol provides an interface to a CA for submitting a PKCS #10
request and receiving a certificate in a PKCS #7 response. ICertPassage has been
superseded in Windows Server 2003 by ICertRequest, but is still used by Windows 2000
clients.
Excerpt of the How Certificate Services Works section of Windows Server 2003 documentation:
● ICertRequest and ICertRequest2. These interfaces accept requests for new and existing
certificates.
● ICertAdmin and ICertAdmin2. These interfaces provide administrative functions, including
request management (modification, denial, resubmission, and revocation), importing certificates,
key archival, CRL management, server configuration, user role retrieval, and certificate data
retrieval.
● ICertView and ICertView2. These interfaces allow properly authorized clients to create a
customized or complete view of the Certificate Services certificates database.
Prev Up Next
4.11.1. Application Management service Home 4.11.3. Client Service for NetWare
4.11.3. Client Service for NetWare
Prev 4.11. Other MSRPC interfaces Next
Prev Up Next
4.11.2. Certificate services Home 4.11.4. Cryptographic Services service
4.11.4. Cryptographic Services service
Prev 4.11. Other MSRPC interfaces Next
The Cryptographic Services service runs three RPC services, available on the following endpoints:
[...]
8d0ffe72-d252-11d0-bf8f-00c04fd9126b v1.0
0d72a7d4-6148-11d1-b4aa-00c04fb66ea0 v1.0
f50aac00-c7f3-428e-a022-a6b71bfb9d43 v.1.0
[...]
[...]
8d0ffe72-d252-11d0-bf8f-00c04fd9126b v1.0
0d72a7d4-6148-11d1-b4aa-00c04fb66ea0 v1.0
f50aac00-c7f3-428e-a022-a6b71bfb9d43 v.1.0
[...]
In Windows Vista, the IKeySvc interface is replaced by the IKeySvc2 interface, with the following
endpoints:
[...]
68b58241-c259-4f03-a2e5-a2651dcbc930 v1.0
0d72a7d4-6148-11d1-b4aa-00c04fb66ea0 v1.0
f50aac00-c7f3-428e-a022-a6b71bfb9d43 v.1.0
[...]
Prev Up Next
4.11.3. Client Service for NetWare Home 4.11.5. DHCP Client service
4.11.5. DHCP Client service
Prev 4.11. Other MSRPC interfaces Next
In Windows Server 2003, the DHCP Client service is running in an svchost.exe instance running under
the NETWORK SERVICE logon session. The DNS Client service is running in the same process.
The DHCP Client service runs one RPC service, available on the following endpoint:
In Windows Vista, the following two interfaces are registered in the endpoint mapper database:
[...]
[...]
In Windows Vista, these interfaces are local-only, using the following endpoints:
Prev Up Next
4.11.4. Cryptographic Services service Home 4.11.6. DHCP Server service
4.11.6. DHCP Server service
Prev 4.11. Other MSRPC interfaces Next
The DHCP Server service runs two RPC services, available on the following endpoint:
Prev Up Next
4.11.5. DHCP Client service 4.11.7. Distributed Link Tracking
Home
Client service
4.11.7. Distributed Link Tracking Client service
Prev 4.11. Other MSRPC interfaces Next
The Distributed Link Tracking Client service, implemented in the trkwks.dll DLL, runs one RPC
service, available on the following endpoints:
[...]
300f3532-38cc-11d0-a3f0-0020af6b0add v1.2
[...]
300f3532-38cc-11d0-a3f0-0020af6b0add v1.2
Prev Up Next
4.11.6. DHCP Server service 4.11.8. Distributed Link Tracking
Home
Server service
4.11.8. Distributed Link Tracking Server service
Prev 4.11. Other MSRPC interfaces Next
Prev Up Next
4.11.7. Distributed Link Tracking Client 4.11.9. DNS Client service - Windows
Home
service 2000
4.11.9. DNS Client service - Windows 2000
Prev 4.11. Other MSRPC interfaces Next
0n Windows 2000, the DNS Client service (caching DNS resolver) runs one RPC service.
Prev Up Next
4.11.8. Distributed Link Tracking 4.11.10. DNS Client service - Windows
Home
Server service XP and later versions
4.11.10. DNS Client service - Windows XP and later versions
Prev 4.11. Other MSRPC interfaces Next
Starting with Windows XP, the DNS Client service runs one RPC service, available on the following
endpoint:
Prev Up Next
4.11.9. DNS Client service - Windows 4.11.11. EFS
Home
2000
4.11.11. EFS
Prev 4.11. Other MSRPC interfaces Next
4.11.11. EFS
The EFS (Encrypted File System) subsystem runs one RPC service, efsrpc, used to communicate with
the service that implement cryptographic operations on the local system.
Prev Up Next
4.11.10. DNS Client service - Windows 4.11.12. Fax server
Home
XP and later versions
4.11.12. Fax server
Prev 4.11. Other MSRPC interfaces Next
Prev Up Next
4.11.11. EFS Home 4.11.13. File Server for Macintosh
4.11.13. File Server for Macintosh
Prev 4.11. Other MSRPC interfaces Next
Prev Up Next
4.11.12. Fax server 4.11.14. IPsec Policy Agent service -
Home
Windows 2000
4.11.14. IPsec Policy Agent service - Windows 2000
Prev 4.11. Other MSRPC interfaces Next
On Windows 2000, the IPsec Policy Agent service runs one RPC service, available on the following
endpoints:
[...]
d335b8f6-cb31-11d0-b0f9-006097ba4e54 v1.5
[...]
d335b8f6-cb31-11d0-b0f9-006097ba4e54 v1.5
Prev Up Next
4.11.13. File Server for Macintosh 4.11.15. IPsec Services service -
Home
Windows XP and later versions
4.11.15. IPsec Services service - Windows XP and later versions
Prev 4.11. Other MSRPC interfaces Next
In Windows XP, the IPsec Services service runs one RPC service on the following endpoints:
[...]
12345678-1234-abcd-ef00-0123456789ab v1.0
Interfaces: 8
[...]
12345678-1234-abcd-ef00-0123456789ab v1.0
In Windows Server 2003, the RPC service does not seem to set a specific endpoint. If the HKLM
\SYSTEM\CCS\Services\PolicyAgent\EnableRemoteMgmt registry value is set to 0 or is not present,
the RPC security callback function prevents remote access to this interface.
In Windows Vista, if the EnableRemoteMgmt registry value is set (it is not set by default), the IPsec
service registers a named pipe endpoint with a randomly-generated name:
[...]
[...]
Prev Up Next
4.11.14. IPsec Policy Agent service - 4.11.16. License Logging service
Home
Windows 2000
4.11.16. License Logging service
Prev 4.11. Other MSRPC interfaces Next
The License Logging service runs two RPC services, available on the following endpoints:
A vulnerability in one of the llsrpc interface operations was discovered by Kostya Kortchinsky and fixed
by the MS05-010 security bulletin [46] in February 2005.
This vulnerability can be exploited anonymously in Windows NT 4.0 and Windows 2000 SP3 because it
is possible to connect anonymously to the llsrpc named pipe on these systems.
Prev Up Next
4.11.15. IPsec Services service - 4.11.17. Microsoft SQL Server
Home
Windows XP and later versions
4.11.17. Microsoft SQL Server
Prev 4.11. Other MSRPC interfaces Next
In addition to the TDS network protocol (by default, on TCP port 1433), it is possible to query an SQL
Server using the RPCnetlib interface. The RPC service is only available if the Multiprotocol transport
has been configured using the SQL Server Network utility.
Protocol sequences for the RPCnetlib interface can be configured in the RPC Protocols entry in the
Multiprotocol properties. In the following example, three transports were configured: ncalrpc,
ncacn_np and ncacn_ip_tcp. The endpoints for each protocol sequence can be obtained by a query to
the portmapper.
Z:\>rpcdump 127.0.0.1
[...]
[...]
Prev Up Next
4.11.16. License Logging service Home 4.11.18. Protected storage service
4.11.18. Protected storage service
Prev 4.11. Other MSRPC interfaces Next
The Protected Storage service runs one RPC service, available on the following endpoints:
[...]
c9378ff1-16f7-11d0-a0b2-00aa0061426a v1.0
[...]
[...]
c9378ff1-16f7-11d0-a0b2-00aa0061426a v1.0
[...]
[...]
11220835-5b26-4d94-ae86-c3e475a809de v1.0
5cbe92cb-f4be-45c9-9fc9-33e73e557b20 v1.0
c9ac6db5-82b7-4e55-ae8a-e464ed7b4277 v1.0
[...]
[...]
[...]
Prev Up Next
4.11.17. Microsoft SQL Server 4.11.19. Routing and Remote Access
Home
service
4.11.19. Routing and Remote Access service
Prev 4.11. Other MSRPC interfaces Next
The Routing and Remote Access service runs one RPC service, available on the following endpoint:
This interface allows remote administration of network parameters, using the netsh command.
[...]
8f09f000-b7ed-11ce-bbd2-00001a181cad v0.0
[...]
Prev Up Next
4.11.18. Protected storage service Home 4.11.20. Secondary Logon service
4.11.20. Secondary Logon service
Prev 4.11. Other MSRPC interfaces Next
The Secondary Logon service runs one RPC service, available on the following endpoints:
[...]
12b81e99-f207-4a4c-85d3-77b42f76fd14 v1.0
Prev Up Next
4.11.19. Routing and Remote Access 4.11.21. Security Configuration Editor
Home
service Engine
4.11.21. Security Configuration Editor Engine
Prev 4.11. Other MSRPC interfaces Next
The Security Configuration Editor Engine runs in the services.exe process context. It runs one RPC
service on the following endpoint:
[...]
93149ca2-973b-11d1-8c39-00c04fb984f9 v0.0
[...]
Prev Up Next
4.11.20. Secondary Logon service 4.11.22. SSDP Discovery Service
Home
service
4.11.22. SSDP Discovery Service service
Prev 4.11. Other MSRPC interfaces Next
Prev Up Next
4.11.21. Security Configuration Editor 4.11.23. System Event Notification
Home
Engine service
4.11.23. System Event Notification service
Prev 4.11. Other MSRPC interfaces Next
The System Event Notification Service runs two RPC service, listening on the following endpoint:
[...]
63fbe424-2029-11d1-8db8-00aa004abd5e v1.0
629b9f66-556c-11d1-8dd2-00aa004abd5e v3.0
[...]
Prev Up Next
4.11.22. SSDP Discovery Service 4.11.24. Telephony service
Home
service
4.11.24. Telephony service
Prev 4.11. Other MSRPC interfaces Next
The Telephony service runs one RPC service on the following endpoints:
Prev Up Next
4.11.23. System Event Notification 4.11.25. Terminal Server service
Home
service
4.11.25. Terminal Server service
Prev 4.11. Other MSRPC interfaces Next
The Terminal Server service runs two RPC services, available on the following endpoints:
Prev Up Next
4.11.24. Telephony service Home 4.11.26. WebClient service
4.11.26. WebClient service
Prev 4.11. Other MSRPC interfaces Next
The WebClient service runs one RPC service, available on the following endpoint:
Prev Up Next
4.11.25. Terminal Server service Home 4.11.27. Windows Audio service
4.11.27. Windows Audio service
Prev 4.11. Other MSRPC interfaces Next
The Windows Audio service runs one or several RPC services, avalailable on the following endpoints:
[...]
3faf4738-3a21-4307-b46c-fdda9bb8c0d5 v1.0
[...]
In Windows XP SP2 and >, the version of the AudioSrv interface is 1.1:
In Windows Vista, the AudioSrv interface (version 1.1) supports fewer operations. A new interface,
AudioRpc, supports more operations:
Operation
Interface Operation name
number
c386ca3e-9061-4a72-
821e-498d83be188f
v1.1: AudioRpc
0x00 AudioServerConnect
0x01 AudioServerDisconnect
0x02 AudioServerInitialize
0x03 AudioServerGetAudioSession
0x04 AudioServerCreateStream
0x05 AudioServerDestroyStream
0x06 AudioServerGetStreamLatency
0x07 AudioServerGetMixFormat
0x08 AudioServerIsFormatSupported
0x09 AudioServerGetDevicePeriod
0x0a AudioVolumeGetMasterVolumeLevelScalar
0x0b AudioSessionGetProcessId
0x0c AudioSessionGetState
0x0d AudioSessionGetLastActivation
0x0e AudioSessionGetLastInactivation
0x0f AudioSessionIsSystemSoundsSession
0x10 AudioSessionGetDisplayName
0x11 AudioSessionSetDisplayName
0x12 AudioSessionGetSessionClass
0x13 AudioSessionSetSessionClass
0x14 AudioSessionGetVolume
0x15 AudioSessionSetVolume
0x16 AudioSessionGetMute
0x17 AudioSessionSetMute
0x18 AudioSessionGetChannelCount
0x19 AudioSessionSetChannelVolume
0x1a AudioSessionGetChannelVolume
0x1b AudioSessionSetAllVolumes
0x1c AudioSessionGetAllVolumes
0x1d AudioServerDisconnect
0x1e AudioServerGetMixFormat
0x1f PolicyConfigGetDeviceFormat
0x20 PolicyConfigSetDeviceFormat
0x21 AudioServerGetDevicePeriod
0x22 PolicyConfigSetProcessingPeriod
0x23 PolicyConfigGetShareMode
0x24 PolicyConfigSetShareMode
0x25 GetAudioSessionManager
0x26 AudioSessionManagerDestroy
0x27 AudioSessionManagerGetAudioSession
0x28 AudioSessionManagerGetCurrentSession
0x29 AudioSessionManagerGetExistingSession
0x2a AudioSessionManagerAddAudioSessionClientNotification
0x2b AudioSessionManagerDeleteAudioSessionClientNotification
0x2c AudioSessionManagerAddAudioSessionClientNotification
0x2d AudioVolumeConnect
0x2e AudioVolumeDisconnect
0x2f AudioVolumeGetChannelCount
0x30 AudioVolumeSetMasterVolumeLevel
0x31 AudioVolumeSetMasterVolumeLevelScalar
0x32 AudioVolumeGetMasterVolumeLevel
0x33 AudioVolumeGetMasterVolumeLevelScalar
0x34 AudioVolumeSetChannelVolumeLevel
0x35 AudioVolumeSetChannelVolumeLevelScalar
0x36 AudioVolumeGetChannelVolumeLevel
0x37 AudioVolumeGetChannelVolumeLevelScalar
0x38 AudioVolumeSetMute
0x39 AudioSessionGetDisplayName
0x3a AudioVolumeAddMasterVolumeNotification
0x3b AudioVolumeDeleteMasterVolumeNotification
0x3c AudioMeterGetAverageRMS
0x3d AudioMeterGetChannelsRMS
0x3e AudioMeterGetPeakValue
0x3f AudioMeterGetChannelsPeakValues
0x40 AudioVolumeGetStepInfo
0x41 AudioVolumeStepUp
0x42 AudioVolumeStepDown
Prev Up Next
4.11.26. WebClient service Home 4.11.28. Windows File Protection
4.11.28. Windows File Protection
Prev 4.11. Other MSRPC interfaces Next
The Windows File Protection subsystem runs inside the winlogon.exe process and supports one RPC
service, available on the following endpoints:
[...]
83da7c00-e84f-11d2-9807-00c04f8ec850 v2.0
[...]
Prev Up Next
4.11.27. Windows Audio service Home 4.11.29. Windows Security Center
4.11.29. Windows Security Center
Prev 4.11. Other MSRPC interfaces Next
The Security Center service was introduced in Windows XP SP2 and supports the SecurityCenter
interface:
Prev Up Next
4.11.28. Windows File Protection Home 4.11.30. Windows Time service
4.11.30. Windows Time service
Prev 4.11. Other MSRPC interfaces Next
The Windows Time service runs one RPC service on the following endpoints:
● W32TIME LPC port (Windows 2000 and Windows XP) and W32TIME_ALT LPC port
(Windows Server 2003, Windows Vista)
● W32TIME named pipe (Windows 2000 and Windows XP) and W32TIME_ALT named pipe
(Windows Server 2003, Windows Vista)
[...]
8fb6d884-2388-11d0-8c35-00c04fda2795 v4.1
[...]
[...]
8fb6d884-2388-11d0-8c35-00c04fda2795 v4.1
[...]
In Windows 2000, different RPC services run in the winlogon.exe process and are available on the
following endpoints:
The last interface is the sfcapi interface, documented in Section 4.11.28, “Windows File Protection”.
Prev Up Next
4.11.30. Windows Time service 4.11.32. Winlogon process - Windows
Home
Server 2003
4.11.32. Winlogon process - Windows Server 2003
Prev 4.11. Other MSRPC interfaces Next
In Windows Server 2003, three additional RPC service are supported inside winlogon.exe. These
interfaces create the following endpoints:
Prev Up Next
4.11.31. Winlogon process - Windows 4.11.33. Wireless Configuration service
Home
2000
4.11.33. Wireless Configuration service
Prev 4.11. Other MSRPC interfaces Next
The Wireless Configuration service runs one RPC service, available on the following endpoint:
[...]
Prev Up Next
4.11.32. Winlogon process - Windows 4.12. MSRPC interfaces introduced in
Home
Server 2003 Windows Vista
4.12. MSRPC interfaces introduced in Windows Vista
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Prev Up Next
4.11.33. Wireless Configuration service Home 4.12.1. Group Policy Client Service
4.12.1. Group Policy Client Service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12. MSRPC interfaces introduced in 4.12.2. Network Location Awareness
Home
Windows Vista
4.12.2. Network Location Awareness
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
[...]
aa411582-9bdf-48fb-b42b-faa1eee33949 v1.0
c33b9f46-2088-4dbc-97e3-6125f127661c v1.0
[...]
[...]
aa411582-9bdf-48fb-b42b-faa1eee33949 v1.0
c33b9f46-2088-4dbc-97e3-6125f127661c v1.0
[...]
Prev Up Next
4.12.1. Group Policy Client Service Home 4.12.3. Network Store Interface
4.12.3. Network Store Interface
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12.2. Network Location Awareness Home 4.12.4. Parental controls
4.12.4. Parental controls
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12.3. Network Store Interface 4.12.5. Peer Networking Identity
Home
Manager
4.12.5. Peer Networking Identity Manager
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12.4. Parental controls Home 4.12.6. Remote Registry Service
4.12.6. Remote Registry Service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Operation
Interface Operation name Windows API
number
0da5a86c5-12c2-4943-
30ab-7f74a813d853
v1.0: perflibv2
0x00 PerflibV2EnumerateCounterSet
0x01 PerflibV2QueryCounterSetRegistrationInfo
0x02 PerflibV2EnumerateCounterSetInstance
0x03 PerflibV2OpenQueryHandle
0x04 PerflibV2CloseQueryHandle
0x05 PerflibV2QueryCounterInfo
0x06 PerflibV2QueryCounterData
0x07 PerflibV2ValidateCounters
Prev Up Next
4.12.5. Peer Networking Identity 4.12.7. Windows event collector service
Home
Manager
4.12.7. Windows event collector service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Operation
Interface Operation name Windows API
number
69510fa1-2f99-4eeb-a4ff-
af259f0f9749 v1.0:
ICollectorService
0x00 EcRpcGetSubscriptionNames
0x01 EcRpcGetSubscription
0x02 EcRpcPutSubscription
0x03 EcRpcDeleteSubscription
0x04 EcRpcGetSubscriptionRunTimeStatus
0x05 EcRpcRetrySubscription
Prev Up Next
4.12.6. Remote Registry Service Home 4.12.8. Windows event logging service
4.12.8. Windows event logging service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
The IEventService interface is the RPC interface used to communicate with the Windows event
logging service service.
The interface is used over a dynamic TCP endpoint, registered in the endpoint mapper database, as
shown below:
[...]
[...]
For more information about the Windows Event Log API, see the documentation in the Microsoft
Windows SDK.
Operation
Interface Operation name Windows API
number
f6beaff7-1e19-4fbb-9f8f-
b89e2018337c v1.0:
IEventService
0x00 EvtRpcRegisterRemoteSubscription
0x01 EvtRpcUpdateRemoteSubscription
0x02 EvtRpcRemoteSubscriptionNextAsync
0x03 EvtRpcRemoteSubscriptionNext
0x04 EvtRpcRemoteSubscriptionWaitAsync
0x05 EvtRpcRegisterLogQuery
0x06 EvtRpcClearLog
0x07 EvtRpcExportLog
0x08 EvtRpcLocalizeExportLog
0x09 EvtRpcMessageRender
0x0a EvtRpcMessageRenderDefault
0x0b EvtRpcQueryNext
0x0c EvtRpcQuerySeek
0x0d EvtRpcClose
0x0e EvtRpcAssertConfig
0x0f EvtRpcRetractConfig
0x10 EvtRpcOpenLogHandle
0x11 EvtRpcGetLogFileInfo
0x12 EvtRpcGetChannelList
0x13 EvtRpcGetChannelConfig
0x14 EvtRpcPutChannelConfig
0x15 EvtRpcGetPublisherList
0x16 EvtRpcGetPublisherMetadata
0x17 EvtRpcGetPublisherResourceMetadata
0x18 EvtRpcGetEventMetadataEnum
0x19 EvtRpcGetNextEventMetadata
Prev Up Next
4.12.7. Windows event collector service Home 4.12.9. Windows Firewall
4.12.9. Windows Firewall
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12.8. Windows event logging service 4.12.10. Windows Wireless LAN
Home
802.11 Auto Configuration Service
4.12.10. Windows Wireless LAN 802.11 Auto Configuration Service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Operation
Interface Operation name Windows API
number
266f33b4-
c7c1-4bd1-
8f52-
ddb8f2214ea9
v1.0: winwlan
0x00 RpcOpenHandle WlanOpenHandle
0x01 RpcCloseHandle WlanCloseHandle
0x02 RpcEnumInterfaces WlanEnumInterfaces
0x03 RpcSetAutoConfigParameter WlanSetAutoConfigParameter
0x04 RpcQueryAutoConfigParameter WlanQueryAutoConfigParameter
0x05 RpcGetInterfaceCapability WlanGetInterfaceCapability
0x06 RpcSetInterface WlanSetInterface
0x07 RpcQueryInterface WlanQueryInterface
0x08 RpcScan WlanScan
0x09 RpcGetVisibleNetworkList WlanGetVisibleNetworkList
0x0a RpcGetNetworkBssList WlanGetNetworkBssList
0x0b RpcConnect WlanConnect
0x0c RpcDisconnect WlanDisconnect
0x0d RpcRegisterNotification WlanRegisterNotification
0x0e RpcAsynGetNotification
0x0f RpcSetProfile WlanSetProfile
0x10 RpcGetProfile WlanGetProfile
0x11 RpcDeleteProfile WlanDeleteProfile
0x12 RpcSetProfileList WlanSetProfileList
0x13 RpcGetProfileList WlanGetProfileList
0x14 RpcSetProfilePosition WlanSetProfilePosition
0x15 RpcSetUserData WlanSetUserData
0x16 RpcSetFilterList WlanSetFilterList
0x17 RpcGetFilterList WlanGetFilterList
0x18 RpcSetPsdlEDataList WlanSetPsdIEDataList
0x19 RpcSaveTemporaryProfile WlanSaveTemporaryProfile
0x1a RpcIsUIRequestPending
0x1b RpcSetUIForwardingNetworkList
0x1c RpcIsNetworkSuppressed
0x1d RpcRemoveUIForwardingNetworkList
0x1e RpcQueryExtUIRequest
0x1f RpcUIReponse
0x20 RpcGetProfileKeyInfo
Prev Up Next
4.12.9. Windows Firewall 4.12.11. Wired Autoconfiguration
Home
Service
4.12.11. Wired Autoconfiguration Service
Prev 4.12. MSRPC interfaces introduced in Windows Vista Next
Prev Up Next
4.12.10. Windows Wireless LAN 4.13. Implication of multiple RPC
Home
802.11 Auto Configuration Service services in one process
4.13. Implication of multiple RPC services in one process
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
One important property of the MSRPC implementation is that inside a given process any RPC services
listening on any protocol sequences can be reached using any opened endpoints.
This specifity of the MSRPC implementation is documented in the MSDN, under the “Be Wary of Other
RPC Endpoints Running in the Same Process” [90] section.
To restrict RPC calls on the server-side, either the RpcServerRegister2() API or the
RpcServerRegisterIfEx() API must be used.
As most Win32 services are implemented in a few processes, hosting many Win32 services (lsass.exe,
services.exe, svchost.exe), a direct consequence is that all RPC services started by any Win32 service in
a given process can be invoked using any opened endpoint in the process context, if RPC services do not
use one of the two APIs earlier mentionned.
Prev Up Next
4.12.11. Wired Autoconfiguration 4.13.1. Win32 services hosting
Home
Service
4.13.1. Win32 services hosting
Prev 4.13. Implication of multiple RPC services in one process Next
The services.exe process host many services, which can be identified looking for services.exe in the
following registry value of each service service_name:
Key: HKLM\SYSTEM\CurrentControlSet\Services\service_name\
Value: ImagePath
Three instances of svchost.exe processes can be found on a Windows 2000 system. Among them, one
instance (netsvcs instance) typically hosts different services. Services hosted in svchost.exe processes
appear in the registry:
More precisely, on Windows 2000 systems, the following Win32 services run in the following
processes:
To determine which services are hosted by which services on a running system, the following tools can
be used:
Prev Up Next
4.13. Implication of multiple RPC 4.13.2. Example of multiple RPC
Home
services in one process services in one process
4.13.2. Example of multiple RPC services in one process
Prev 4.13. Implication of multiple RPC services in one process Next
Using ifids with the eventlog named pipe endpoint, opened by the Eventlog service running in the services.exe process, the
list of interface identifiers is:
Using another endpoint, for example, the dynamic UDP port opened by the messenger service (also running in the services.
exe process), the result is identical:
These results show that all RPC services in the services.exe process can be reached using any opened endpoint on any
transport.
Using our knowledge of RPC interface identifiers, we can identify some of the Win32 services currently running in the
services.exe process:
● Eventlog
● Dnscache
● ProtectedStorage
● lanmanserver
● lanmanworkstation
● Messenger
● PlugPlay
● W32Time
Actually, the complete list of Win32 services running inside the services.exe process is:
C:\WINNT>tlist /s
[...]
[...]
Prev Up Next
4.13.1. Win32 services hosting 4.13.3. Implications of running multiple RPC
Home
services in one process
4.13.3. Implications of running multiple RPC services in one process
Prev 4.13. Implication of multiple RPC services in one process Next
The direct consequence of running multiple RPC services in one process is that, if one RPC service is
listening on an endpoint like a TCP port or a named pipe, all RPC services can be reached using that
particular endpoint.
Thus, even if a RPC service listens only on the ncalrpc protocol (in order to accept only local procedure
calls), it can be used remotely as long as another RPC service in the same process listens on a TCP port
or a named pipe.
Another consequence is that it allows to anonymously identify some Win32 services remotely, as shown
in the previous section:
● Services running in the lsass.exe process can be identified, using the lsarpc, samr, netlogon
named pipes as MSRPC endpoint (these named pipes can always be opened in the context of a
SMB NULL session)
● Some services in the services.exe process can be identified, using either the dynamic UDP port
opened by the messenger service as MSRPC endpoint or the wkssvc, srvsvc or browser named
pipes (they can always be opened in the context of a SMB NULL session).
● Identifying Win32 services running in svchost.exe instances can be more difficult, in particular
when RPC services contained in that processes do not open endpoints that can be used remotely.
Note: this also explains why one RPC interface identifier can appear more than once in the rpcdump
output, with different endpoints on different protocol sequences: these correspond to endpoints opened
by RPC services in the same process.
Prev Up Next
4.13.2. Example of multiple RPC 4.14. RPC services protection
Home
services in one process
4.14. RPC services protection
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Typically, a security-callback function verifies that the protocol sequence used by a client is legal. For
instance, it is thus possible to forbid access to RPC services that are supposed to be used only locally,
even if the process that hosts RPC services also runs RPC services listening on named pipes or TCP or
UDP sockets.
When these APIs are used, it usually implies that only a subset of all the interfaces that appear on the
output of the ifids command can be reached, using dedicated endpoints.
Prev Up Next
4.13.3. Implications of running multiple 4.15. RPC interfaces restriction in
RPC services in one process Home Windows XP SP2, Windows Server
2003 SP1 and later versions
4.15. RPC interfaces restriction in Windows XP SP2, Windows Server 2003 SP1 and later
versions
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
The RestrictRemoteClients registry value (Restrictions for Unauthenticated RPC Client GPO), not
present by default but with a default value of 1 (RPC_RESTRICT_REMOTE_CLIENT_DEFAULT)
prevents anonymous binding to RPC interfaces, typically using the ncacn_ip_tcp transport.
In particular, the restriction applies to RPC interfaces running in the rpcss service, including the
endpoint mapper (epmp) interface. Yet, it is still possible to query the endpoint mapper anonymously
using the ncacn_np protocol sequence with the \pipe\epmapper named pipe as endpoint.
For more information, see the RPC Interface Restriction section in the Network Protection technologies
chapter in the Changes to Functionality in Microsoft Windows XP Service Pack 2 document [94] and
the #838191 Microsoft knowledge base article [95].
The RestrictRemoteClients registry value (Restrictions for Unauthenticated RPC Client GPO) also
exists in Windows Server 2003 SP1 but its default value is 0 (restrictions are disabled). It is
recommended to set it to 1 (RPC_RESTRICT_REMOTE_CLIENT_DEFAULT) or 2
(RPC_RESTRICT_REMOTE_CLIENT_HIGH).
Prev Up Next
4.14. RPC services protection Home 4.16. MSRPC vulnerabilities
4.16. MSRPC vulnerabilities
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Follows a list of Microsoft security patches that fixed vulnerabilities related to MSRPC, either in the
MSRPC subsystem or in system components running MSRPC services:
The following table lists the MSRPC interfaces that were affected by vulnerabilities:
Microsoft
Affected MSRPC interface Affected
Security Publication Date Reference
(s) software
Bulletin
Windows NT
MS99-020 June 23, 1999 lsarpc CVE-1999-0721
4.0
December 09, Windows NT
MS99-055 srvsvc CVE-1999-0980
1999 4.0
December 16, Windows NT
MS99-057 lsarpc CVE-1999-0995
1999 4.0
Windows NT
MS00-040 June 08, 2000 winreg CVE-2000-0377
4.0
MS00-062 August 28, 2000 lsarpc Windows 2000 CVE-2000-0771
Windows NT
4.0, 2000,
MS01-041 July 26, 2001 Multiple interfaces CVE-2001-0509
Exchange, SQL
Server
September 10, Windows NT
MS01-048 epmp CVE-2001-0662
2001 4.0
Windows NT
MS03-001 January 22, 2003 locator CVE-2003-0003
4.0, 2000, XP
Windows NT
MS03-010 March 26, 2003 epmp CVE-2002-1561
4.0, 2000, XP
ISystemActivator, Windows NT
MS03-026 July 16, 2003 IRemoteActivation 4.0, 2000, XP, CVE-2003-0352
(IActivation) Server 2003
CVE-2003-
ISystemActivator, Windows NT 0528, CVE-
September 10,
MS03-039 IRemoteActivation 4.0, 2000, XP, 2003-0605,
2003
(IActivation) Server 2003 CVE-2003-
0715
Windows NT
MS03-043 October 15, 2003 msgsvc 4.0, 2000, XP, CVE-2003-0717
Server 2003
November 11, Windows 2000,
MS03-049 wkssvc CVE-2003-0812
2003 XP
Windows 2000,
MS04-011 April 13, 2004 dssetup CVE-2003-0533
XP
CVE-2004-
IRemoteActivation Windows 2000,
MS04-012 April 13, 2004 0116, CVE-
(IActivation) XP
2004-0124
Windows NT CVE-2004-
MS04-031 October 12, 2004 nddeapi 4.0, 2000, XP,
0206
Server 2003
MS05-007 February 8. 2005 srvsvc Windows XP CVE-2005-0051
Windows NT
MS05-010 February 8, 2005 llsrpc 4.0, 2000, CVE-2005-0050
Server 2003
Windows 2000,
MS05-017 April 12, 2005 qmcomm CVE-2005-0059
XP SP1
Windows 2000,
MS05-039 August 9, 2005 pnp CVE-2005-1983
XP, Server 2003
Windows 2000,
MS05-040 August 9, 2005 tapsrv CVE-2005-0058
XP, Server 2003
Windows 2000,
MS05-043 August 9, 2005 spoolss CVE-2005-1984
XP, Server 2003
Windows 2000,
MS05-046 October 11, 2005 nwwks CVE-2005-1985
XP, Server 2003
Windows 2000,
MS05-047 October 11, 2005 pnp CVE-2005-2120
XP
Windows 2000,
MS05-051 October 11, 2005 IXnRemote CVE-2005-2119
XP, Server 2003
Windows XP,
MS06-008 February 14, 2006 davclntrpc CVE-2006-0013
Server 2003
CVE-2006-
Windows 2000,
MS06-018 May 9, 2006 IXnRemote 0034, CVE-
XP, Server 2003
2006-1184
● Multiple remote DoS vulnerabilities in Microsoft DCE/RPC deamons (Todd Sabin, July 2001)
● Windows 2000 DCOM clients may leak sensitive information onto the network (Todd Sabin,
April 2002)
● DCE RPC Vulnerabilities New Attack Vectors Analysis (Javier Kohen, Juliano Rizzo, December
2003)
● Anonymous attackers can force DCOM applications into listening on the network (Todd Sabin,
October 2004)
● Telnet to Port 135 Causes 100 Percent CPU Usage (Windows NT 4.0)
● Denial of Service in Applications Using RPC over Named Pipes (Windows NT 4.0)
● A truncated Samba server response causes an access violation in the Lsass.exe program on a
Windows XP-based client computer (Windows XP)
Prev Up Next
4.15. RPC interfaces restriction in 4.17. MSRPC network traffic
Windows XP SP2, Windows Server Home
2003 SP1 and later versions
4.17. MSRPC network traffic
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
Being able to analyze MSRPC network traffic is important for several reasons:
Prev Up Next
4.16. MSRPC vulnerabilities 4.17.1. MSRPC network traffic analysis
Home
with Ethereal
4.17.1. MSRPC network traffic analysis with Ethereal
Prev 4.17. MSRPC network traffic Next
Ethereal is certainly the best network analyzer to analyze MSRPC traffic. The following features are
supported:
● Ability to analyze MSRPC traffic over TCP, UDP, SMB and SMB2.
● Decoding of the following MSRPC interfaces: atsvc, browser, dnsserver, drsuapi, dssetup, efsrpc,
eventlog, frsapi, frsrpc, InitShutdown, lsarpc, mapi, msgsvcsend, netdfs, netlogon, nspi, pnp, rras,
samr, spoolss, srvsvc, svcctl, tapsrv, trksvr, winreg, wkssvc
● Ability to decrypt MSRPC traffic encrypted with Kerberos, when the appropriate keys are
specified in a keytab file.
● Service response time statistics on a per-interface basis
The DCE RPC dissector of Ethereal is a heuristic dissector and will try to dissect TCP segments or UDP
datagrams as DCE RPC Protocol Data Units. Sometimes, this can lead to incorrect dissections, when the
dissector believes that data correspond to DCE RPC traffic when it is not the case. In that case, it is
possible to force the dissection with another protocol, using the Decode As feature.
The DCE RPC dissector is able to keep track of the interface bound between a client and a server, to be
able to decode appropriately the PDUs. If the network trace does not contain enough information (BIND
or similar PDUs), Ethereal will stop the dissection at the DCE RPC level. In that case, it is possible to
use the Decode As DCE RPC function to force the dissection as one of the DCE RPC interfaces
supported by Ethereal.
For MSRPC over SMB traffic, the SMB dissector calls the DCE RPC dissector for any named pipe
different from the LANMAN pipe. This is because the LANMAN pipe is used to carry RAP (Remote
Administration Protocol) traffic and not DCE RPC traffic.
Some of the MSRPC dissectors are auto-generated using IDL files and two different IDL compilers, Pidl
from the Samba project and idl2eth, part of Ethereal.
The dissectors involved in the dissection of MSRPC traffic handle data reassembly, so that the DCE
RPC dissector can reassemble fragmented DCE RPC PDUs. For best results, the following dissector
options have to be enabled:
Prev Up Next
4.17. MSRPC network traffic 4.17.2. MSRPC network traffic analysis
Home in Network Intrusion Prevention
Systems
4.17.2. MSRPC network traffic analysis in Network Intrusion Prevention Systems
Prev 4.17. MSRPC network traffic Next
Because of the numerous vulnerabilities discovered in MSRPC (see Section 4.16, “MSRPC
vulnerabilities”), Network Intrusion Prevention and Detection Systems must inspect MSRPC traffic to
detect or block malicious traffic.
Because the protocols involved (SMB, MSRPC) are complex, implementation of MSRPC traffic
analysis in a network security device is a complex task that requires a good understanding of the
protocols. Several evasion techniques are possible if the implementation of these protocols is not
complete.
The successive improvements in NFR's MSRPC package gives a good idea of the work required to
successfully implement MSRPC in NIPS:
● RAPID RESPONSE - MSRPC Version 21 (MS06-018 and Feature Upgrades): MSRPC package,
version 21.
● MAINTENANCE - MSRPC Version 20: MSRPC package, version 20.
● RAPID RESPONSE - MSRPC Version 19 (MS05-047 and MS05-051): MSRPC package,
version 19.
● RAPID RESPONSE: MSRPC Version 18 for MS05-039 (UPnP) exploit: MSRPC package,
version 18.
● Beyond "Blaster" - MSRPC Evasions: nfr(sensor), June 2005.
● UPDATE - MSRPC Version 16: MSRPC package, version 16.
● MAINTENANCE - MSRPC Update (Version 15): MSRPC package, version 15.
● RAPID RESPONSE - MSRPC Update (v14) for MS05-007 and MS05-010 Microsoft
vulnerabilities: MSRPC package, version 14.
● MAINTENANCE: Updated SMB Version 5 and MSRPC Version 13 packages available:
MSRPC package, version 13.
● MAINTENANCE - MSRPC Update (Version 11) and SMB Update (Version 3): MSRPC
package, version 11.
● Blasting "Blaster"-Detecting the MSRPC DCOM hole: nfr(sensor), fall 2003
● MSRPC Package Update - New Version of MSRPC (Version 10) Contains Important Bugfixes:
MSRPC package, version 10.
● Important MSRPC DCOM package update - MS Messenger Service (MS03-043): MSRPC
package, version 9.
● Important Note for all customers - MSRPC DCOM Rapid Response Update (Version 8): MSRPC
package, version 8.
● Important Note for all customers - MSRPC DCOM Rapid Response Update: MSRPC package,
version 7.
● Important Note for all customers - MSRPC DCOM Rapid Response Update: MSRPC package,
version 6.
● DCOM Worm/MSRPC Update for NID-100 and NID-200 Customers: MSRPC package, version
5.
● UPDATED MS-RPC Rapid Response from NFR RRT: MSRPC package, version 4.
● UPDATED MS-RPC Rapid Response from NFR RRT: MSRPC package, version 2.
● NEW Package available to detect MSRPC DoS: MSRPC package, version 1.
Prev Up Next
4.17.1. MSRPC network traffic analysis 4.17.3. MSRPC network traffic analysis
Home
with Ethereal in Firewalls
4.17.3. MSRPC network traffic analysis in Firewalls
Prev 4.17. MSRPC network traffic Next
To properly implement a network security policy in Windows environments, it might be desirable to use
firewalls that support MSRPC.
Depending on the completeness of the implementation, MSRPC support in a firewall might include the
following features:
With Windows Server 2003 SP1, a modification to the MSRPC implementation was introduced. As a
consequence, firewalls implementing sanity checks on MSRPC traffic started to block traffic originating
from these systems because the software did not consider the traffic as valid. Software updates are
available from the different vendors to fix the problem.
Prev Up Next
4.17.2. MSRPC network traffic analysis 4.18. DCOM
in Network Intrusion Prevention Home
Systems
4.18. DCOM
Chapter 4. MSRPC, a.k.a. Microsoft implementation of
Prev Next
DCE RPC
4.18. DCOM
4.18.1. COM interfaces
4.18.2. DCOM network traffic
For a good introduction to COM and DCOM, see Implementing Distributed COM in Samba, written by
Jelmer Vernooij (Samba Team Member).
The Distributed Component Object Model Protocol -- DCOM/1.0 Internet Draft, published by Microsoft
in January 1998, is still available.
Prev Up Next
4.17.3. MSRPC network traffic analysis 4.18.1. COM interfaces
Home
in Firewalls
4.18.1. COM interfaces
Prev 4.18. DCOM Next
A process that hosts COM objects will typically support interfaces among the following ones:
The IRemUnknown2 interface inherits from the IRemUnknown interface and adds one method,
RemQueryInterface2.
Definitions of core COM interfaces can be obtained in IDL files published by the WINE project:
● unknwn.idl
● objidl.idl
● oleidl.idl
● ocidl.idl
The Oleview Microsoft tool can be used to examine and analyze registered COM interfaces on a
Windows system.
Prev Up Next
4.18. DCOM Home 4.18.2. DCOM network traffic
4.18.2. DCOM network traffic
Prev 4.18. DCOM Next
The Understanding the DCOM Wire Protocol by Analyzing Network Data Packets article, published in
the March 1998 issue of the Microsoft Systems Journal publication, documents how DCOM is
implemented at the network level.
The DCOM wire protocol uses DCE RPC as its transport protocol. Ethereal supports the DCOM wire
protocol and has dissectors for the following core COM interfaces:
● IOXIDResolver
● ISystemActivator and IRemoteActivation
● IRemUnknown and IRemUnknown2
● IDispatch
When analyzing DCOM traffic with Ethereal, it is recommended to use the Windows version of Ethereal
because it is able to use the Windows registry to translate IID's (GUID's) to interfaces names.
Prev Up Next
4.18.1. COM interfaces Home Chapter 5. Conclusion
Chapter 5. Conclusion
Prev Next
Chapter 5. Conclusion
Because of the proprietary nature of the Windows operating system, Windows network services
internals have been progressively documented by independent researchers.
In the past, many vulnerabilities have been discovered in the Windows SMB and MSRPC
implementations. Recently, multiple vulnerabilities in the MSRPC implementation have been published.
Prev Next
4.18.2. DCOM network traffic Home Bibliography
Bibliography
Prev
Bibliography
[1] Implementing CIFS: http://www.ubiqx.org/cifs/
[4] NAT Clients Cannot View Web Sites After You Install SQL 2000 SP2 or SP3 on an RRAS Server:
http://support.microsoft.com/?id=324288
[6] App Request UDP Only, "Netstat -an" Displays TCP and UDP: http://support.microsoft.com/?
id=194171
[7] The NETSTAT Command Incorrectly Shows Ports in Listening States: http://support.microsoft.
com/?id=331078
[12] HOW TO: Determine Which Program Uses or Blocks Specific Transmission Control Protocol Ports
in Windows http://support.microsoft.com/?id=281336
[13] The netstat command can now display process IDs that correspond to active TCP or UDP
connections in Windows 2000: http://support.microsoft.com/?id=907980
[14] TCPView: http://www.sysinternals.com/Utilities/TcpView.html
[23] BUG: Non-administrator users cannot set the SO_EXCLUSIVEADDRUSE option on the Winsock
setsockopt API call: http://support.microsoft.com/?id=870562
[26] HOW TO: Install Microsoft Loopback Adapter in Windows 2000: http://support.microsoft.com/?
id=236869
[35] DCE 1.1: Remote Procedure Call - Introduction to the RPC API: http://www.opengroup.org/
onlinepubs/9629399/chap2.htm#tagfcjh_2
[45] You Can Use The Llsrpc Named Pipe to Add or Delete Licenses and Create New License Groups:
http://support.microsoft.com/?id=815458
[46] Vulnerability in the License Logging Service Could Allow Code Execution (885834): http://www.
microsoft.com/technet/security/bulletin/ms05-010.mspx
[47] Vulnerability in Web Client Service Could Allow Remote Code Execution (911927) http://www.
microsoft.com/technet/security/bulletin/ms06-008.mspx
[65] Buffer Overrun in the Workstation Service Could Allow Code Execution (828749): http://www.
microsoft.com/technet/security/bulletin/ms03-049.mspx
[67] Vulnerability in Print Spooler Service Could Allow Remote Code Execution (896423): http://www.
microsoft.com/technet/security/bulletin/ms05-043.mspx
[73] Understanding the DCOM Wire Protocol by Analyzing Network Data Packets: http://www.
microsoft.com/msj/0398/dcom.aspx
[74] Microsoft Windows 2000 RPC DCOM Interface DOS AND Privilege Escalation Vulnerability:
http://www.securiteam.com/exploits/5CP0N0KAKK.html
[76] Unchecked Buffer in Locator Service Could Lead to Code Execution (810833): http://www.
microsoft.com/technet/security/bulletin/MS03-001.mspx
[78] Buffer Overrun in Messenger Service Could Allow Code Execution (828035): http://www.
microsoft.com/technet/security/bulletin/MS03-043.mspx
[81] TCP ports, UDP ports, and RPC ports that are used by Message Queuing: http://support.microsoft.
com/?id=178517
[82] Vulnerability in Message Queuing Could Allow Code Execution (892944): http://www.microsoft.
com/technet/security/bulletin/ms05-017.mspx
[84] Windows Local Security Authority Service Remote Buffer Overflow: http://www.eeye.com/html/
Research/Advisories/AD20040413C.html
[88] RPC Interfaces That Are Exposed by Secure Mail Publishing in ISA Server 2000: http://support.
microsoft.com/?id=304948
[90] Be Wary of Other RPC Endpoints Running in the Same Process: http://msdn.microsoft.com/library/
en-us/rpc/rpc/be_wary_of_other_rpc_endpoints_running_in_the_same_process.asp
[93] DCE/RPC over SMB: Samba and Windows NT Domain Internals. Luke Kenneth Casson Leighton.
Macmillan Technical Publishing, 2000.
[94] RPC Interface Restriction: Changes to Functionality in Microsoft Windows XP Service Pack 2
(Part 2: Network Protection Technologies) http://www.microsoft.com/technet/prodtechnol/winxppro/
maintain/sp2netwk.mspx#EHAA
[95] List of Remote Procedure Call (RPC) fixes in Windows XP Service Pack 2 and in Windows XP
Tablet PC Edition 2005: http://support.microsoft.com/?id=838191
Prev
Chapter 5. Conclusion Home