Services Introduction

Services are programs or processes that function to provide one or more services to the operating system and its security principals. In general, a service program usually has the following characteristics:

• It can start when the OS starts up.

• It does not require a user to be logged in to load.

• It often logs on with a security principal account that has full system access.

• It is controlled by the Service Control Manager (SCM) process.

• It creates and accepts local or network connections.

Although users or newly installed programs can install services, Windows installs with dozens of default services (although they are not all activated). As Table 7-1 shows, the number of installed and activated services increases with each new version of Microsoft Windows.

Table 7-1 reveals that the number of total services almost doubled between Windows 2000 and the newer operating systems.

These are just the default Windows services installed on a computer not running any special services or programs (the lone exception in Table 7-1 is the DNS Server service to provide DNS support for Active Directory domain controller services). Certainly, Windows Vista will have more available services than did any of the previous operating systems. Many Microsoft Windows applications install services, including IIS, SQL, Exchange, Certificate Services, SMS, SharePoint Services, ISA, BizTalk, and others. Each separate Windows application service can install up to 10 new services.

Original Equipment Manufacturer (OEM) computers, such as those from Dell, HP, IBM, and Compaq, install additional services. Sometimes the OEM vendor installs up to 20 new programs and 10 new services on each desktop and server computer they sell. In the past, OEM services have been just as likely to be exploited as Microsoft's default services. On top of this, many other installed software and hardware products install services. It is common to see one or more services installed to manage the network interface and video cards. Most often, the additional services aren't needed to use the component cards, but they add additional management interfaces. Software programs, such as tape backup software, antivirus programs, firewalls, Wincap, Microsoft SQL Server Desktop Edition, Seti@home, Distributed.Net, and thousands of other programs install new services. It is not unusual for a normal PC to be running more than 100 active services. Each of these services is taking up processor power and memory — and each is a potential attack vector for an attacker. Determining whether a service is legitimate or not is important to computer security.

Identifying Unknown Services

If you are unfamiliar with a service, you can search on its name by using any good Internet search engine (e.g., Google), by using Microsoft's Knowledge Base, or by searching in any of the Internet websites that provide information on found programs and services (e.g., www.theeldergeek.com/services_guide.htm). When using a search engine, if the service name frequently appears on spyware or antivirus sites, it isn't a good sign. Although there are exceptions, any legitimate service should be well documented, and several links noting its legitimacy should be found. If no Internet information is provided and the service name is spelled correctly, disable the service and consider it suspicious until otherwise discovered.

All Microsoft services are well documented. Sysinternals' Autoruns program (www.sysinternals.com/utilities/autoruns.html) is also good for determining program legitimacy. As Figure 7-1 shows, Autoruns shows the service file name, location, size, and description. Autoruns can be configured to verify the code signatures of any service program and to hide verified Microsoft services by default. This enables an investigator to quickly reveal any unsigned services. Occasionally, Microsoft installs unsigned service applications, but not often. Any unsigned or non-Microsoft service should be investigated if its legitimacy is not known. Autoruns also includes an easy way to search Google for more information on the revealed service.

Figure 7-1

Service Details

Services and their details are normally accessed by running the Services console, Services.msc, or by right-clicking the My Computer icon, choosing the Manage option, and then choosing Services on the resulting Computer Management console. Using either method you can access local or remote computers. The console will open with the list of installed services (see Figure 7-2). You can choose between Standard and Extended views. The Extended view will display the service's description in the left pane when a service is highlighted. Both views have the description field and allow columns to be resized and sorted.

Figure 7-2

Note 

You can also run the command-line tool Sc.exe to display service information. It is included in some Windows versions by default or you can download it as part of the Windows Resource Kit utilities.

For analysis purposes, the Services console can be used to export a list of services and the information displayed in the main summary view. To export a list of services from the Services console, right-click the Services object in the top left pane, choose Export List, and choose the file name, type, and location of the exported file. The exported file can be easily opened in Microsoft Excel or Access for further analysis.

If the service is double-clicked on or opened, the Services console will reveal the following details (Windows 2000 and later): General, Logon, Recovery, and Dependencies.

General

As Figure 7-3 shows, the General tab displays many different useful fields regarding the service. The Service Name displays the service's short name. The short name is often how the service is referred to and is often required to use various service utilities. The Display Name is the service's name to be shown in the Services console (and other places). For example, the service with the short name of Browser has a display name of Computer Browser. Users often know it by its Display Name, but programmers and scripters know it by its short name. The Description field should hold some information about the service and why it is installed. Frequently, third-party, and occasionally Microsoft, services do not have a description. Services without descriptions should get extra scrutiny.

Figure 7-3

The path to the executable is an important field. Not only does it display the underlying executable that is executed with the service (and often the name displayed is not what would be commonly expected); it also shows the full path location (albeit with older 8.3 naming) to the executable and startup switches.

Attackers will often install rogue services with official-sounding Microsoft Windows names, but they have to install them in non-default locations (because they can't overwrite a legitimate file that is protected by Windows File Protection). The executable name here is usually what is presented in the Processes tab of the Task Manager.

Multiple Services, One Name

The executable name is where it sometimes gets interesting. Although most service executables are named identically to the service's short name, others have no obvious relationship. Many services point to the same executable (e.g., Svchost.exe, Lsass.exe, Dllhost.exe, etc.). This is because the service's code is within the larger executable and is "called out." For example, all of the following services start using the Lsass.exe image: IPSec Services, Net Logon, NT LM Security Support Provider, Protected Storage, and Security Accounts Manager. At least two services start with the Dllhost.exe image: COM+ System Application and the MS Software Shadow Copy Provider. But the mack daddy image of them all is Svchost. %\Windir%\System32\Svchost.exe is responsible for nearly half of all default Windows services, including Alerter, Automatic Updates, Cryptographic Services, Computer Browser, DHCP Client, DNS Client, Messenger, Task Scheduler, Terminal Services, and Windows Firewall.

When an investigator looks at processes in Task Scheduler or using Netstat.exe -ano, instead of seeing the service's short name, they will see the executable name. If the investigator is not expecting it, they can be confused because several of the same file images are running at once, and many of the services may not appear to be running at all. When Svchost.exe, in particular, starts up, it queries the registry key (HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Svchost) to find out which programs it should run and over how many separate instances of Svchost. The active processes running under each Srvhost.exe image can also be found by typing in Tasklist /svc at the command prompt. Its response might look something like this:

 Image Name                   PID Services ========================= ====== ============================================= System Idle Process            0 N/A System                         4 N/A smss.exe                    1244 N/A csrss.exe                   1364 N/A winlogon.exe                1388 N/A services.exe                1432 Eventlog, PlugPlay lsass.exe                   1444 Netlogon, PolicyAgent, ProtectedStorage,                                  SamSs svchost.exe                 1628 DcomLaunch, TermService svchost.exe                 1676 RpcSs svchost.exe                 2016 AudioSrv, CryptSvc, Dhcp, ERSvc,                                  EventSystem, helpsvc, lanmanserver,                                  lanmanworkstation, Netman, Nla, Schedule,                                  seclogon, SENS, SharedAccess,                                  ShellHWDetection, srservice, Themes, TrkWks,                                  winmgmt, wuauserv, WZCSVC svchost.exe                  200 Dnscache svchost.exe                  676 LmHosts, RemoteRegistry, SSDPSRV, WebClient spoolsv.exe                 1268 Spooler scardsvr.exe                1316 SCardSvr alg.exe                      772 ALG iexplore.exe                 568 N/A tasklist.exe                2452 N/A 

In this example, one Svchost.exe instance (with a PID of 2016) is running 14 different services, while other instances are running a single service. You can see what services are running under Lsass.exe, as well as the executable image behind each actively running service.

Startup Type

The Startup Type has three possible values: Automatic, Manual, and Disabled. Automatic means it starts when the system starts. A service with an Automatic Startup Type will run whenever the system starts, without having to wait for a user to log on. A service with a Manual Startup Type will not start automatically when the system starts, but can be started by other services or programs dependent on it, or manually by an administrator. Many services marked Manual start each time Windows starts, but just as many wait to be called by another program or process. For example, the Application Management service only starts when it is needed by Active Directory group policy objects trying to push down a software install. A service marked Disabled cannot be started by any program, process, or user until its Startup Type is changed. Table 7-2 shows the percentage of services with each Startup Type as compared to the percentage of services that start automatically when Windows starts (i.e., Manual or Automatic Startup Type).

Table 7-2

OS	Total	Started by Default	Startup Type
			Automatic	Disabled	Manual
2000	56	54%	43%	5%	52%
XP	79	52%	44%	5%	51%
W2K3	83	39%	35%	25%	40%
W2K3 DC	84	44%	39%	23%	26%

You can see Microsoft's efforts to strengthen the operating system. Although the number of installed services has increased over time, the percentage activated by default has fallen and the percentage disabled by default has increased. This chapter builds on Microsoft's defaults.

Note 

Be aware that changing a service's Startup Type does not affect whether it is running or not at the current time.

Status can be Started, Stopped, or Paused. In XP Pro and later, by default only admins can change a service's status manually. There are many ways to stop and start a service, including using the Net Start or Net Stop syntax. For example:

 Net Stop DHCP 

This will stop the DHCP client. Note that the short name is used. Optionally, admins can pass the service command-line parameters to execute, although most of the time the switches are passed in the executable path field.

LogOn

The LogOn tab (see Figure 7-4) contains one of the most important fields of any service — the service account. All services log on using a service account (or service account principal). A service account is nearly identical to a normal user account. It can be local or domain-based but with a few differences. When a security principal account is registered as a service account, it gains the Logon as a service user right (in Local Computer Policy or a group policy object under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment: Log on as a service). When this occurs, the service account logon will be managed by the Service Control Manager (SCM).

Figure 7-4

Note 

There is also a related service principal name (SPN) used for Kerberos delegation that this chapter will not be discussing. See http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAServicePrincipalNameSPN.html for more details.

Default Service Accounts

You can enter any existing valid security principal account or use one of the three security principal accounts that exist in Windows by default: LocalSystem (known as System), LocalService, or NetworkService. The latter two accounts only exist in Windows XP and later, and were created to allow Windows services to be tightened. Prior to Windows XP, all services ran in the LocalSystem context. The LocalSystem context is the most powerful account in Windows. It has Full Control access to all objects; and even when an object's permissions are denied, it will be able to access the object with Full Control-Allow permissions.

To enable a service to use the LocalSystem account (sometimes displayed as NT AUTHORITY\System) as most services do, enable the Local System account option under the Log on as selection. Alternately, you can choose to enable Allow service to interact with the desktop, but this option is almost never enabled. If you allow a service to interact with the desktop, when the service displays information, it will be displayed on any currently logged in interactive user's desktop. A malicious user logged in interactively could take control of the service or attack it.

Although not used a lot yet (see Tables 7-3 and 7-4), LocalService and NetworkService can be used where LocalSystem access is not needed. When chosen, LocalService is displayed as NT AUTHORITY\LocalService. The LocalService account has the same permissions as an Authenticated User on the local machine but connects to any remote computers using a null session (i.e., anonymous null session). NetworkService (i.e., NT AUTHORITY\NetworkService) accesses the local computer and network using the credentials of the local computer account. Typically, the local computer account belongs to the Authenticated Users, Everyone, and Domain Computer groups by default. Tables 7-3 and 7-4 show common Windows services that use LocalService and NetworkService in Windows XP and Windows Server 2003.

Services Logging On as LocalService

Alerter (disabled by default in XP and later)

Application Layer Gateway Service

Remote Registry

Smart Card

Smart Card Helper (only in Windows XP)

SSDP Discovery Service (only in Windows XP)

TCP/IP NetBIOS Helper

Telnet (LocalSystem in XP)

Uninterruptible Power Supply

Universal Plug and Play Device Host

WebClient

Windows Image Acquisition (not installed until an image device is installed)

Windows Time (LocalSystem in XP)

Windows User Mode Driver Framework (new in Windows Server 2003 SP1)

WinHTTP Web Proxy Auto-Discovery Service (only in Windows Server 2003)

Services Logging On as NetworkService

ASP.NET State Service (not installed by default)

DHCP Client (LocalSystem in XP)

Distributed Transaction Coordinator

DNS Client

License Logging (in Windows Server 2003 only)

Performance Logs and Alerts

Remote Procedure Call (RPC) (made NetworkService in XP SP2 and Windows Server 2003 SP1)

Remote Procedure Call (RPC) Locator

Update Services (only in Windows Server 2003, not a default installed service)

The number of services listed in Tables 7-3 and 7-4 differ from the figures reported in 7-1 because Tables 7-3 and 7-4 include non-default services and cover both XP and Server 2003 operating systems.

Note 

Windows Vista will contain even more services running under the LocalService and NetworkService accounts.

When installing new services, consider using one of the newer, lesser privileged service accounts instead of using LocalSystem or an administrative-level user account.

Custom Service Accounts

Any user account can become a service account. It must have the Log on as a service user right and have access permissions to the objects it will manipulate. Simply enter (or browse to) the user account in the Services console Log On tab and type the password twice. Windows will automatically add the selected account as a service account, tell SCM to manage it, and store the password locally.

Service Account Passwords

Service accounts are also unique in that any entered passwords are stored both in the normal locations (SAM or Active Directory) and in the local system's LSA secrets cache (as covered in Chapter 4). (You should never change the passwords of the LocalSystem, LocalService, or NetworkService accounts. Windows maintains and changes them and ensures that they are sufficiently complex to prevent easy password hacking). As previously shown, it is possible for an admin user to extract those passwords in near plaintext using Lsadump2.exe, Cain & Able, and other programs. If you use a custom service account, make sure the password is long and complex and that it is changed more frequently than your normal user accounts. But also know that if a user has admin access to a computer with a customized service account, the logon name and password can be extracted even when the password is long and complex. This is not the case when the service account is one of the normal defaults (i.e., LocalSystem, LocalService, or NetworkService). The risk of having custom service account passwords cracked by an admin user must be weighed against the benefits of using a custom account in the first place.

Note 

You can also enable or disable any service on a per-service, per-hardware profile basis. Disable services when they are not needed in various profiles.

Recovery

As Figure 7-5 shows, the Recovery tab covers how Windows should treat an unnaturally stopped or nonresponding service. You can select how Windows should respond during the first, second, and sub-sequent failures. Windows response objects are Take No Action, Restart the Service, Run a Program, or Restart the Server. The default response is to Take No Action. The Recovery feature was made specifically to address overloaded, buggy, or maliciously attacked services. You can set how long failures are counted before the failure counter is reset to zero. Restart the Service allows a service to be recovered, at least temporarily, if being subjected to a massive DoS attack. You can set the number of minutes before restarting a service in order to allow another type of response or to send a message to connected users.

Figure 7-5

The default recovery action is often Take No Action or Restart the Computer for many services. For high-risk computers or services, consider instead setting the default action to Run a Program and send an alert to the first responders so they can troubleshoot or have early warning of a malicious attack. If you suspect that a service is going to be under attack, consider running a passive program to capture more detailed data, or another active response tool (such as an IPS or script). Figure 7-5 shows the command-line network packet capturing program, Tethereal.exe, being started on the third failure. If you decide to restart the computer, you can attempt to send a message to connected users.

Dependencies

The Dependencies tab (see Figure 7-6) was added in Windows XP, but you can also see Windows 2000 dependencies if you open a Windows 2000 remote machine in an XP or later Services console. Dependencies show what services a particular depends on and what services depend on it. Prior to the Dependencies tab, a user would have to randomly shut off different services (or dig in the registry) to get warning messages to learn what services depended on what. Now one tab shows the needed information.

Figure 7-6