If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

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

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:

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

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.

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.

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:

&gt; 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.

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

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

If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)

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.

- 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

If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)