Results 1 to 9 of 9

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

  1. #1
    Senior Member
    Join Date
    Mar 2004

    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


    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]
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  2. #2
    the beign of authority kurt_der_koenig's Avatar
    Join Date
    Jan 2004
    Wow! Very good, very nice. A good read sec_ware!

  3. #3
    Senior Member
    Join Date
    Oct 2004
    GREAT!!! Very helpfull!!
    Thank you very much sec-ware for doing that tutorial! I will try everything what you wrote!
    Remember, all I\'m offering is the truth, nothing more.

  4. #4
    Senior Member
    Join Date
    Mar 2004

    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.

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

  5. #5
    great subject,
    thanx man

  6. #6
    Wow! Very good, very nice. A good read sec_ware!
    same here!!
    keep up the good work !

  7. #7
    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.
    From Abhishek Dwivedi.

  8. #8
    Junior Member
    Join Date
    Nov 2005

    Thumbs up

    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?


  9. #9
    Senior Member
    Join Date
    Mar 2004

    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

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts