Service Accounts

Service account is an unofficial term used to describe a Windows user account that
launches and runs a service non-interactively (a more traditional computing term is batch
accounts). Service accounts are typically not used by human beings for interactive logon,
but are used to start up and run automated routines that provide certain functionality to
the operating system on a continuous basis. For example, the Indexing service, which
indexes contents and properties of files on local and remote computers, and is located in
%systemroot%\System32\cisvc.exe, can be configured to start up at boot time using the
Services control panel. For this executable to run, it must authenticate to the operating
system. For example, the Indexing service authenticates and runs as the LocalSystem
account on Windows Server 2003 in its out-of-the-box configuration.
Service accounts are a necessary evil in Windows. Because all code must execute in
the context of an account, they cant be avoided. Unfortunately, because they are
designed to authenticate in an automated fashion, the passwords for these accounts
must be provided to the system without human interaction. In fact, Microsoft designed
the Windows NT family to cache passwords for service accounts on the local system.
This was done for the simple convenience that many services need to start up before the
network is available (at boot time), and thus could not be authenticated to domain
controllers. By caching the passwords locally, this situation is avoided. Heres the
kicker:
Non-SYSTEM service account passwords are stored in cleartext in a portion of the Registry
called the LSA Secrets, which is accessible only to LocalSystem.
We highlighted this sentence because it leads to one of the major security failings of the
Windows OS: If a malicious hacker can compromise a Windows NT family system with
Administrator-equivalent privileges, he or she can extract the cleartext passwords for
service accounts on that machine.Yippee, you might be saying, if youre already Administrator-equivalent on the
machine; What additional use are the service accounts? Heres where things get
sticky: Service accounts can be domain accounts or even accounts from other trusted
domains. (See the section Trusts later in this chapter.) Thus, credentials from other
security domains can be exposed via this flaw. Youll read more about how this is done
in Chapter 7.
Service Hardening Services represent a large percentage of the overall attack surface in
Windows because they are generally always on and run at high privilege. Largely because
of this, Microsoft began taking steps to reduce the risk from running services in more
recent versions of the OS.
One of the first steps was to run services with least privilege, a long-accepted access
control principle. Beginning in Windows Server 2003, Microsoft created two new built-in
groups called Local Service and Network Service, and started running more services
using those lower privileged accounts rather than the all-powerful LocalSystem account.
(Well talk more about Local and Network Service throughout this chapter.)
In Vista, Microsoft implemented Windows Service Hardening, which defined per-
service SIDs. This effectively made certain services behave like unique users (again, as
opposed to the generic and highly privileged LocalSystem identity). Default Windows
access control settings could now be applied to resources in order to make them private
to the service, preventing other servi
ces and users from accessing the resource.
Additional features included within Service Hardening in Vista include removal of
unnecessary Windows privileges (such as the powerful debugging privilege), applying
a write-restricted access token to the service process to prevent writing to resources
that do not explicitly grant access to the Service SID, and linking Windows firewall
policy to the per-service SID to prevent unauthorized network access by the service.
For more information about Service Hardening, see References and Further
Reading.