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

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 :)

Introduction

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.

Prerequisites

The tools
.netstat
.tasklist
.services.msc
.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.
.rpcdump[3]
.ifids[3]

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)

Code:

> netstat -ano Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:23 0.0.0.0:0 LISTENING 1632 TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1088 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 1192 TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING 1828 TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:2869 0.0.0.0:0 LISTENING 1452 TCP 0.0.0.0:3019 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1192 TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING 1452 TCP 0.0.0.0:42424 0.0.0.0:0 LISTENING 1960 TCP 127.0.0.1:3001 0.0.0.0:0 LISTENING 1932 TCP 127.0.0.1:3002 0.0.0.0:0 LISTENING 1192 TCP 127.0.0.1:3003 0.0.0.0:0 LISTENING 1192 TCP 192.168.1.21:139 0.0.0.0:0 LISTENING 4 TCP 192.168.1.21:139 192.168.1.10:1516 ESTABLISHED 4 TCP 192.168.1.21:3019 192.168.1.13:445 ESTABLISHED 4 UDP 0.0.0.0:445 *:* 4 UDP 0.0.0.0:500 *:* 888 UDP 0.0.0.0:1645 *:* 1192 UDP 0.0.0.0:1646 *:* 1192 UDP 0.0.0.0:1812 *:* 1192 UDP 0.0.0.0:1813 *:* 1192 UDP 0.0.0.0:3026 *:* 1420 UDP 0.0.0.0:3066 *:* 1420 UDP 127.0.0.1:123 *:* 1192 UDP 127.0.0.1:1900 *:* 1452 UDP 127.0.0.1:3004 *:* 1192 UDP 127.0.0.1:3005 *:* 1192 UDP 192.168.1.21:123 *:* 1192 UDP 192.168.1.21:137 *:* 4 UDP 192.168.1.21:138 *:* 4 UDP 192.168.1.21:1900 *:* 1452

Tasklist tells us the corresponding process that is associated with the PID:

Code:

> 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

Code:

Service DLL/EXE Context Ports Distributed Transaction Coordinator Msdtc.exe TCP 1026 Dynamic! (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).

Code:

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 SharedAccess)

.Lsass

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!).

Code:

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

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 192.168.1.13 - another machine
sharing a directory (Linux machine, Samba share).
A quick view on TCP 139 (established) relates it with an active share from 192.168.1.10, 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:

Code:

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 (Messenger)

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

.1027

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).

Code:

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

Code:

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

.Svchost (PID 1452)

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

Code:

Service DLL/EXE Context Ports Universal Plug and Play Device Host upnphost.dll Svchost TCP 2869 (upnphost) 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.

Code:

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 Dynamic! Windows Time w32time.dll Svchost UDP 123 W32time) 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.

Code:

Service DLL/EXE Context Ports Remote Procedure Call (RPC) rpcss.dll Svchost TCP 135 (RpcSs) 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.

Code:

> rpcdump –p ncacn_ip_tcp 127.0.0.1 > rpcdump –p ncadg_ip_udp 127.0.0.1

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

Code:

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

and

Code:

IfId: 906b0ce0-c70b-1067-b317-00dd010662da version 1.0 Annotation: UUID: 9c23bb81-cc6d-44e5-8fc9-65f7c3096aad Binding: ncacn_ip_tcp:127.0.0.1[1026]

The IfId (Interface ID’s) can be uniquely mapped to the service running. These are, in our case:

Code:

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.

Code:

> ifids –p ncacn_ip_tcp –e 1025 127.0.0.1

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

Code:

> netstat -ano Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1084 TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 1188

- trick: closing TCP 135 and 1025

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

Code:

> 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.

Conclusion

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] http://www.antionline.com/showthread...r=1#post810823
[ 1] http://www.foundstone.com/index.htm?...desc/fport.htm
[ 2] http://www.sysinternals.com/ntw2k/fr.../procexp.shtml
[ 3] http://www.bindview.com/Support/RAZO...1.0-readme.cfm
[ 4] http://www.antionline.com/showthread...r=1#post810823
[ 5] http://www.antionline.com/showthread...r=2#post805365
[ 6] http://www.antionline.com/showthread...r=1#post799358
[ 7] http://support.microsoft.com/kb/325930
http://msdn.microsoft.com/library/de...adg_ip_udp.asp
http://msdn.microsoft.com/library/de...adg_ip_udp.asp
http://msdn.microsoft.com/library/de..._reference.asp
[ 8] http://www.hsc.fr/ressources/article...h04s09s02.html
[ 9] http://www.hsc.fr/ressources/article...h04s09s05.html
[10] http://www.securityspace.com/smysecu...src=1&id=10736
[11] http://www.firewallleaktester.com/wwdc.htm

Wow! Very good, very nice. A good read sec_ware! :thumbsup:

GREAT!!! Very helpfull!!
Thank you very much sec-ware for doing that tutorial! I will try everything what you wrote!

Hi

Thanks to all for the nice feedback.
Note, there are small differences in different versions of
XP/Win2k, but the main strategy should work for all of them.
In any case: Danielsd, if you have any problem, just pm me.
Good luck.

Cheers

great subject,
thanx man

Quote:

Wow! Very good, very nice. A good read sec_ware!

same here!!
keep up the good work !

Hello Sec_Ware,
Brilliant tutorial (brilliant LOOKING for me, because I cannot comprehend much of it).But I know brilliance,even when I am blinded by it. I want to pose some queries to you :
1] Does one have to learn about the working of the 15,000 or so lines of source code of the TCP/IP protocol to understand computer security or "ethical hacking" in depth?
2] I am a moderate C programmer.How much of this skill can help me to learn about effective computer security?
If you have the patience to answer these queries in brief,then please do.
Thank you.

Great tutorial!

I'm trying to replay this on a Win2k station.
But there is something I can't figure out:

For svchost and lsass, how did you map the ports to the services and how did you retrieve the DLL/EXE name?

Regards,
Swappy

Hi

What I have described should also work on Win2k machines.

- via the registry, as described in the above reference [0], you identify
the services running under the context svchost oder lsass, and in
addition the corresponding DLL/EXE name. You also can use Sysinternals
ProcessExplorer via "Properties.Services".

- you assign the ports for example via ProcessExplorer "Properties.TcpIp"
as a first step of information gathering, start/stop services or take an
educated guess. If dynamically assigned, it may be needed or helpful,
maybe not, to use rpcdump and identify the IfId's.

If you have a specific problem, don't hesitate to send me a pm. We can
resolve the issue in a dialog and then post a note here, if needed.
In a long term view, it might be interesting to enhance the functionality
of the currently available "port mapper"-tools (fport, vision, PE, ...) to resolve
for the corresponding exe/dll/service. If such a tool does not exist (I never
actually checked), I may work on this in December or January :)

Cheers