Towards understanding listening ports, SvcHost.exe, System and Services (Tutorial)

This tutorial deals with services, which run under the context of SvcHost.exe, Lsass.exe and System,
and how they can be related to listening ports. The focus is set onto Windows XP pro SP1.

It is organised as follows:
In the introduction, the scope of the tutorial is defined. Using the tools mentioned in the prerequisites,
I will present how to gather basic information about the processes involved – and their relation to listening
ports. Then, we will systematically identify the services related to the PIDs, themselves related to listening
ports. This is a non-trivial task and will have to dive into rpc calls. Finally, I will briefly add some comments about
firewall settings.

There is/was great confusion about this kind of thing. Some part has been presented in [0].
After that post, I was encouraged to write a tutorial, hence here it is.

A remark:
Maybe I will mention some more general concepts without defining them properly. I think, this is beyond the
scope of this tutorial, but on the same time allows the interested reader to dive more deeply into the material
– hopefully


From a technical point of view onto computer security, it is of prime importance to understand how “processes”
in a closed system can interact with each other and with the outer world. Sloppily spoken, this is known as
InterProcess Communication (IPC). NT has seven primary IPC mechanisms (DCOM, named pipes, NetBIOS, NetDDE,
mailslots, RPC and Winsock). Some of them can and do make use of the TCP/IP and UDP protocols. The endpoint to a
logical connection based on TCP/IP and UDP is called a port.

We will get to know some tools which allow for a further investigation of specific IPC mechanisms (eg. RPC also
makes use of named pipes). However, we restrict ourselves to services which intercommunicate by “offering the
TCP/IP and UDP language via listening ports”.

Fport[1] and Process Explorer[2] are useful to some extend, but due to the strategy of componentized windows services,
we (or at least I) cannot track the port back to the single end-service without some work. And this is unsatisfactory!
The essence of the componentized windows services is to gather services (often dll’s) under some name. Svchost.exe
is an essential ingredience, allowing dll’s to run as services. Some of these single services are assigned to a
port , of which some are dynamically given. This complicates things.


The tools
.Fport[1]: Get the PID of the processes related to listening ports.
.Process Explorer[2]: Same. However, several techniques are used in order to determine the process and thus,
these results are more reliable than fport. Note, there is no port-to-process mapping support in Windows 2000.

I cannot recommend any books.

Listening ports and PIDs

One naďve idea is to stop/start services and check for changes in the list of listening ports. So, we need to
know which services are relevant. In most cases, the ports are fixed and hence, known. To track down the corresponding
services is not so difficult. Why naďve? Some ports are assigned dynamical, and hence, it is not very easy to track
those down.

Let us start with a untypical Windows XP professional SP1 port assignment plot (almost all services are running).
We make use of netstat and tasklist in order to relate listening ports with a PID, the process ID.

(file: netstat_full.txt, tasklist_full.txt)

> netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP                 LISTENING       1632
  TCP                LISTENING       1088
  TCP                LISTENING       4
  TCP               LISTENING       1192
  TCP               LISTENING       1828
  TCP               LISTENING       4
  TCP               LISTENING       1452
  TCP               LISTENING       4
  TCP               LISTENING       1192
  TCP               LISTENING       1452
  TCP              LISTENING       1960
  TCP              LISTENING       1932
  TCP              LISTENING       1192
  TCP              LISTENING       1192
  TCP              LISTENING       4
  TCP      ESTABLISHED     4
  TCP       ESTABLISHED     4
  UDP            *:*                                    4
  UDP            *:*                                    888
  UDP           *:*                                    1192
  UDP           *:*                                    1192
  UDP           *:*                                    1192
  UDP           *:*                                    1192
  UDP           *:*                                    1420
  UDP           *:*                                    1420
  UDP          *:*                                    1192
  UDP         *:*                                    1452
  UDP         *:*                                    1192
  UDP         *:*                                    1192
  UDP       *:*                                    1192
  UDP       *:*                                    4
  UDP       *:*                                    4
  UDP      *:*                                    1452
Tasklist tells us the corresponding process that is associated with the PID:

> Tasklist /SVC

Image Name                   PID Services                                     
========================= ====== =============================================
System                         4 N/A                                          
lsass.exe                    888 NtLmSsp, PolicyAgent, ProtectedStorage, SamSs
svchost.exe                 1088 RpcSs                                        
svchost.exe                 1192 AppMgmt, AudioSrv, BITS, Browser, CryptSvc,  
                                 Dhcp, dmserver, ERSvc, EventSystem,          
                                 FastUserSwitchingCompatibility, helpsvc,     
                                 lanmanserver, lanmanworkstation, Messenger,  
                                 Netman, Nla, NtmsSvc, RasAuto, RasMan,       
                                 RemoteAccess, Schedule, seclogon, SENS,      
                                 SharedAccess, ShellHWDetection, srservice,   
                                 TapiSrv, TermService, Themes, TrkWks,        
                                 uploadmgr, W32Time, winmgmt, WmdmPmSp, Wmi,  
                                 wuauserv, WZCSVC                             
svchost.exe                 1420 Dnscache                                     
svchost.exe                 1452 Alerter, LmHosts, RemoteRegistry, SSDPSRV,   
                                 upnphost, WebClient                          
msdtc.exe                   1828 MSDTC                                        
alg.exe                     1932 ALG                                          
aspnet_state.exe            1960 aspnet_state                                 
tlntsvr.exe                 1632 TlntSvr
What can we see?
We see some listening ports, which can uniquely identified with an executable, for example Tlntsvr.exe
is listening on TCP 23 (Telnet service). However, we see a couple of instance of svchost.exe
(PIDs 1088, 1192, 1420, 1452) and also of System (PID 4). Furthermore, Port UDP 500 is related to lsass,
but there we see 4 services running. Which one uses Port UDP 500?

This is the problem we want to deal with here: How to uniquely identify the listening port to a service,
not just the context (“svchost”, “system”, “lsass”) it is running under. The basic part has been partly
presented in [4]. After that post, I was encouraged to write a tutorial, hence here it is.

Identify “simple” PIDs

.simple processes

Service					DLL/EXE			Context		Ports
Distributed Transaction Coordinator	Msdtc.exe				TCP 1026
										(see RPC services)
ASP.NET State Service			aspnet_state.exe			TCP 42424
Telnet					Tlntsvr.exe				TCP 23

.Internet Connection Firewall (ICF)

The Application Layer Gateway Service (alg.exe) is needed for the Internet Connection Firewall. In addition,
SharedAccess (ipnathlp.dll) is needed, which runs under the context of Svchost! Before dealing with the details
of Svchost, let us just put those information together (obtain the port-information by stopping these services).

Service					DLL/EXE			Context		Ports
Application Layer Gateway Service	Alg.exe			ICF		TCP 3001 
										(or 3004, 3007, …)
Internet Connection Firewall		ipnathlp.dll		ICF		TCP 3002
								Svchost		TCP 3003


Listening Port UDP 500 is connected with Lsass. But which of the four services really does need a port?
It is the PolicyAgent (the IPSec service!).

Service					DLL/EXE			Context		Ports
IPSec					ipsec.sys		Lsass		UDP 500

Identify System Services (PID 4), partly Svchost

(file: netstat_simplePIDs.txt, tasklist_simplePIDs.txt)

The ports connected with PID 4 are TCP 445, TCP 1027, TCP 139, TCP 3019, UDP 445, UDP 137, UDP 138.

.SMB over TCP/IP and SMB over NetBIOS (CIFS) [5]

A quick view on TCP 3019 (established) relates it with an active share to - another machine
sharing a directory (Linux machine, Samba share).
A quick view on TCP 139 (established) relates it with an active share from, accessing our box.

Note: Netstat reports the state of TDI transport addresses (sockets), and hence somewhat confuses states
(Listening on Port 3019).

TCP 445 is SMB over TCP/IP, TCP 139 is SMB over NetBIOS, which also includes UDP 137 and UDP 138.

UDP 137,138/TCP 139: We can “close” these ports by disabling NetBIOS over TCP/IP via “Network Connections.Local Area Network(or so).Properties”.
Note, that the messenger also makes use of Port TCP 139.

- trick: closing TCP 445

We can “close” this port by a registry tweak:
In HKLM\System\CurrentControlSet\Services\NetBT\Parameters
set TransportBindName to a blank value. Reboot.
Note: With this tweak, a lot of ports will be closed.

The services related with these ports are running under the Context of Svchost unfortunately. For completeness, I mention them here:

Service				        DLL/EXE			Context		Ports
Computer Browser			browser.dll		Svchost		CIFS/SMB
								(Browser)	TCP 139
										TCP 445

Server					srvsvc.dll		Svchost		CIFS/SMB
								(Lanmanserver)	TCP 139
										TCP 445

TCP/IP NetBIOS Helper Service		lmhsvc.dll		Svchost		CIFS/SMB
								(LmHosts)	TCP 139
										TCP 445

Workstation				wkssvc.dll		Svchost		CIFS/SMB
								(lanmanworkstation)	TCP 139
										TCP 445

Messenger				sgsvc.dll		Svchost		TCP 139

There is no need for the TCP/IP NetBIOS Helper Service (and Messenger probably), which can be disabled.
The others are pretty much crucial.


What is TCP 1027?
This question is not easy to answer – it is, like in the case of the Distributed Transaction Coordinator (TCP 1026),
a dynamically assigned port. The answer has to be evaluated by trial-and-error (well, more or less).

Service					DLL/EXE			Context		Ports
Remote Access Connection Manager	rasmans.dll		Svchost		TCP 1027
								(RasMan)	Dynamic!

You cannot stop that service once running. You have to disable it and reboot.

Identify Svchost services

(file: netstat_SYSTEM.txt, tasklist_ SYSTEM.txt)

As is mentioned in [4], Svchost can have several instances. Each instance is related with some services. Let’s track
them down one by one:

.Svchost (PID 1420) - Dnscache

Service					DLL/EXE			Context		Ports
DNS Client				dnsrslvr.dll		Svchost		UDP 3026 
								(DncCache)	UDP 3066


.Svchost (PID 1452)

The corresponding ports are TCP 2869, TCP 5000, UDP 1900. These ports are well known[6]

Service					DLL/EXE			Context		Ports
Universal Plug and Play Device Host	upnphost.dll		Svchost		TCP 2869

SSDP	Discovery Service		ssdpsrv.dll		Svchost		TCP 5000
								(ssdp)		UDP 1900

.Svchost (PID 1192)

There is a huge amount of services running under this PID, as well as listening ports: TCP 1025, TCP 3389, UDP 1645,
UDP 1646, UDP 1812, UDP 1813, UDP 123, UDP 3004, UDP 3005, UDP 123.

The identification however, is quite easy, except for TCP 1025. TCP 1025 and TCP 1026 are different from TCP 1027,
because they should be accessible in general. Hence, there must be a kind of registration. These are RPC services
and we will deal with them later on.

Service					DLL/EXE			Context		Ports
Routing and Remote Access		mprdim.dll		Svchost		UDP 1645
								(RemoteAccess)	UDP 1646

										UDP 1812
										UDP 1813
										UDP 3004
										UDP 3005
Windows Time				w32time.dll		Svchost		UDP 123	
Terminal Services			termsrv.dll		Svchost		TCP 3389
(Remote Desktop Connection)					(TermService)

- trick: closing TCP 3389

The Remote Desktop can be disabled via “Control Panel.System.Remote”, which closes this port.

.Svchost (PID 1088) - RpcSs

Almost done. We still have unidentified:
TCP 135 and 1025.

Service					DLL/EXE			Context		Ports
Remote Procedure Call (RPC) 		rpcss.dll		Svchost		TCP 135

Task Scheduler				schedsvc.dll		Svchost		TCP 1025
								(Schedule)	Dynamic!
										(see RPC services)

The RPC service cannot be disabled. It is crucial for the system to work, however, the listening port 135 can be closed,
see below. The portmapper finally also allows us to identify the services running on TCP 1025 and TCP 1026 using two tools:
rpcdump and ifids (well, 1026 already is known).

Identify RPC services

If some ports are dynamically assigned, there must be some kind of register of which services is assigned to which port.
Otherwise, there is no way to define communication between processes unambiguous. The RPC portmapper stores this kind of
information. To get access, we make use of the tool rpcdump.

> rpcdump –p ncacn_ip_tcp
> rpcdump –p ncadg_ip_udp
With ncacn_ip_tcp we use to talk tcp, ncadg_ip_udp to talk udp[7].
The first line will return quite a few lines. The interesting one (here) are of type

IfId: 0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53 version 1.0
UUID: 00000000-0000-0000-0000-000000000000
Binding: ncacn_ip_tcp:[1025]

IfId: 906b0ce0-c70b-1067-b317-00dd010662da version 1.0
UUID: 9c23bb81-cc6d-44e5-8fc9-65f7c3096aad
Binding: ncacn_ip_tcp:[1026]
The IfId (Interface ID’s) can be uniquely mapped to the service running. These are, in our case:

Port TCP 1025: [8]
1ff70682-0a51-30e8-076d-740be8cee98b: Scheduler service
378e52b0-c0a9-11cf-822d-00aa0051e40f: Scheduler service
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53:  Scheduler service

Port TCP 1026: [9]
906b0ce0-c70b-1067-b317-00dd010662da: DCE service (Distributed Transaction Coordinator)
Nevertheless, Port 1025 is not closed if we stop the Task Scheduler service, although rpcdump does not return
anything listening on tcp 1025. In order to understand what’s going on, we have to communicate manually with
port 1025 using ifids.

> ifids –p ncacn_ip_tcp –e 1025
The output still is a list of numbers (interface identification number). A tool[10] might come in handy.

If we stop the services mentioned, we end up with a net
> netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP                LISTENING       1084
  TCP               LISTENING       1188

- trick: closing TCP 135 and 1025

A tool, which deactivates DCOM+ is needed[11].
After a reboot:

> netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
And still resulting in a (almost) fully functional box. This work has been written and posted using a system
without any listening TCP/UDP port.

Firewall settings

This recommendations are for a single home PC user and/or small network facilities. In a lot of cases, it is
also appropriate for large scale networks. However, I am here dealing with Svchost.exe and SYSTEM only.

In principle, you can allow DHCP (67-68) and DNS (53) requests by svchost.exe.
In order to be able to share files allow (445) to SYSTEM, but restrict allowed IPs.
In order to send messages, allow UDP 137 and TCP 139 to SYSTEM (also make sure about allowed IPs). I strongly
recommend to disable NetBIOS over TCP/IP. That’s it.


In a quite lengthy tutorial I have shown how to relate listening ports with the service behind them. I hope I
was able to give some insight and help the interested reader to analyse his own system. I tried to avoid as
many mistakes as possible, but if there are some, do not hesitate to contact me. By closing the TCP/UDP ports,
a lot of standard attacks can be completely defeated, however I want to remember that there are seven IPCs.
Each of them could give another tutorial

List of references

[ 0]
[ 1]
[ 2]
[ 3]
[ 4]
[ 5]
[ 6]
[ 7]
[ 8]
[ 9]