The fact that program code contains security holes and that these are exploited by attackers has now become part of everyday life in the IT world. In addition to regularly installing patches to eliminate these security holes, another important measure is to reduce the impact of an attack as much as possible. The fifth part of our (E)SAE Deep Dive series is about reducing highly privileged accounts for Windows Services.

In most cases, an attacker who succeeds in taking over a service will be granted extensive privileges. Service accounts are often local administrators on the systems on which the service is installed, have sysadmin privileges on databases of the application and thus full access to all data of the application. A best practice that has been common for many years is therefore the Least Privilege principle. This means that a user of an IT system or an application only has the authorizations that are absolutely necessary for his or her task.

In practice, however, this is often not so easy to implement because software manufacturers unfortunately all too often do not take the trouble to document these minimally necessary authorizations. Unfortunately, Microsoft did not set a good example. When Windows NT 3.1 was released in 1993, all services ran under LocalSystem with unlimited local permissions. It was not until Windows XP/Windows Server 2003 that Microsoft introduced the LocalService and NetworkService accounts and applied the Least Privilege Principle to the pre-installed services. As a result, even third-party manufacturers were slow to reduce the permissions of their services and this is by no means yet widely practiced. As a result, many manufacturers still frequently specify local administration authorizations as a requirement, without these high levels of authorization actually being necessary. In the worst case, the manufacturer documentation recommends installing services as a domain administrator, which should never be the case. Domain administrator accounts are used exclusively for the administration of domain controllers!

Administrative dependencies

Why is the reduction of permissions so important? To understand this, it is helpful to briefly explain the concept of security dependencies. A security dependency is when the security of one computer system depends on the security of another. In an Active Directory domain, the security of all domain members depends on the security of all domain controllers because, by default, a domain administrator has local administrative permissions on each domain member or can obtain corresponding permissions, e.g., through Group Policy, through a domain member’s trust relationship with the domain in the default configuration. This security dependency is unavoidable and unacceptable. The implication of this is that domain controllers must be operated in a particularly secure manner.

We already described various attack scenarios in the last article of our E(SAE) blog series. In this context, another attack scenario arises from the way credentials of a service account are stored on the system. Windows starts a service with the service account stored in the service configuration. Windows checks the account’s password with the LsaLogonUser function and returns an access token if successful. However, the password of the service account must be stored locally. Windows stores it in the registry under HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets, also known as LSA Secrets. The LSA secrets are encrypted with the system key that is used to decrypt and load the LSA secrets into memory when Windows starts. Here you can find a PowerShell script to decode the LSA Secrets. The tool Mimikatz is also able to do this. So with local administrator privileges it is easy to read the credentials of a service account and if this account still has high privileges on other systems, as is the case with a domain administrator, this offers extensive possibilities to compromise other systems.

Since in this example the password of a domain administrator can be read by a member server, the security of all domain controllers depends on the security of this one server. In this case it is usually an unacceptable security dependency. This is because a sensitive system must never depend on the security of a less sensitive system. Domain controllers host all user accounts and their credentials for a domain and should in almost every case be more sensitive than a member server, even if it also stores extremely sensitive data.

These dependencies are of course not limited to domain controllers. It is also unacceptable that a service account of a web server has local administrator rights on the backend database server. The list of examples can be continued as long as you like. In order to reduce the permissions to a minimum, we first need to understand what permissions exactly are and how to find out which permissions exactly are needed. We will show you this in the next sections.

Service-Accounts and permissions

An application in the Windows environment is usually installed as a service that runs in the background similar to a UNIX daemon. Windows services can be run under different accounts:

• One of the predefined local accounts LocalSystem, LocalService or NetworkService.
• A local user account in the local SAM database.
• An Active Directory user account.

Permissions
Privileges and user rights, as well as permissions on objects together. Objects that support access permissions via Access Control Lists include the NTFS file system, registry, services and Active Directory. Applications such as Microsoft SQL Server also have their own authorization model.

The difference between privileges and user rights is that a user right such as Allow log on locally (SeInteractiveLogonRight) is only checked during logon, whereas privileges are also checked after logon when certain actions are performed, such as when the user changes the time, whether the user has the privilege Change the system time (SeSystemtimePrivilege). The table in User Rights Assignment lists privileges and user rights.

However, there are some so-called super-privileges that are so powerful that an account that has one of these privileges has full control over the system:

• debug programs
• Take ownership
• Restore files and directories
• Load and unload device drivers
• Create a token object
• Act as part of operating system

If a service account requires one of these privileges, this should be checked with the manufacturer of the software.

Predefined accounts
Services can use one of the following predefined accounts. Microsoft recommends that you use one of these accounts if possible:

• LocalSystem: The Access Token contains the Security Identifier (SIDs) of BUILTIN\Administrators and therefore has unlimited rights on the local system. Uses the local system computer account when accessing network resources. (The computer account uses the name of the system with a $ sign as a suffix).
• LocalService: This account has the permissions of BUILTIN\Users and some additional privileges. Accesses network resources as Anonymous Logon.
• NetworkService: Has the same local permissions as LocalService and accesses network resources as LocalSystem with the computer account of the local system.

The disadvantage of the predefined accounts, however, is that they are used by many Windows Services and therefore detailed logging is limited. This is often a reason to use a user account in Active Directory as a service account.

Local Accounts
User accounts in the local SAM can also be used as service accounts. In practice, however, local user accounts should generally be avoided. An exception can be kiosk mode systems that are not members of a domain.

Active Directory Accounts
An Active Directory user account as a service account can be managed centrally and the account can be assigned the minimum necessary permissions on the relevant systems on which the service is installed.

Determine the minimum required permissions

But what do you do if the authorizations of the service account are not documented by the manufacturer? First, you should approach the manufacturer and ask for the technical information. If this is unsuccessful, one should not yet throw in the towel. It is possible that an escalation might also lead to a result with other customers, e.g. via a user group. If this is not the case, or if the software is self-written, there is still the possibility of finding out by technical means which authorizations the service account requires.

The two most common options are Windows Auditing and the tool Procmon as part of the Sysinternals Suite. Windows Auditing requires no additional software and can monitor both Windows OS and Active Directory. Procmon offers even more and more flexible possibilities for Windows OS.

Windows Auditing
First there is Windows Auditing, which allows you to monitor access to resources like files. Auditing is part of Windows and does not require any additional software. In the Audit Policy the category Audit object access must be activated first. It is sufficient to log only failed accesses.

Activating Object Access activates a whole range of individual categories, such as File System and Registry, as can be seen in the output of audipol.exe.

However, this does not automatically log failed accesses to all files. For this purpose, a System Access Control List  (SACL) must be defined for the corresponding directories and files.

Thus the failed access is noted in the Security Event Log with Event ID 4656:

Auditing in the Domain
Auditing also works for Active Directory. To do so, the category Audit directory services access must be activated in the Default Domain Controllers Policy.

Again, some individual categories are activated in the Audit Policy.

SACLs must again be defined for the Active Directory objects to be monitored.

Thus the failed access is noted in the Security Event Log with Event ID 4662:

See the Active Directory Auditing documentation for a list of Auditing Event IDs.

Sysinternals Procmon
The Procmon tool is part of the Sysinternals Suite and is able to monitor file system, registry, process and thread activity, as well as transferring network packets. This allows all failed accesses of a process to be logged.

The monitoring of Procmon is active immediately after program start and generates hundreds of entries. Therefore it makes sense to create a filter rule for this scenario that only monitors failed entries.

A failed access is then displayed when it occurs. Below is an example of a failed write attempt to a file:

The monitored entries can then also be saved and exported to XML or CSV if required.

Implementation

If the minimum required permissions have been determined using the methods described above and the software is commercial software, it is still advisable to clarify the support implications with the manufacturer before changing the permissions of the service account.

Overall, a larger company will have thousands of services installed on Windows systems. Therefore, prioritization is necessary in the first instance. For services that are part of Windows, the permissions are not changed anyway. Depending on the deployment scenario, unneeded services are deactivated. This is usually done by implementing security baselines provided by Microsoft or other organizations such as the Center for Internet Security (CIS) or the U.S. Department of Defense (DOD) for different versions of Windows.

Client management suites such as Microsoft Endpoint Manager are helpful for inventorying services. If such a tool is not available, an inventory with scripts can also be performed using tools such as PowerShell. In this way the services can be classified according to manufacturer.

A prioritization should first of all focus on services that are accessible via the network and have high privileges. Whether a service listens on network ports can be determined locally using tools such as netstat or Get-NetTCPConnection. For a remote scan e.g. nmap can be used.

The implementation of the privileges then depends on the concrete requirements of the application. Usually ACLs on file system or registry are involved or the configuration of certain rights via local security policies. Particularly if service accounts are to be authorized on several systems, an automation with PowerShell is recommended. Here tools like icacls and Set-Acl can be used. Some applications such as Microsoft SQL Server also offer their own tools for this purpose, such as the SQL Server Configuration Manager, which configures all necessary permissions for the service account.

When assigning permissions within the Active Directory, groups (according to the IGDLA principle) should be used and the permissions should be configured using the Delegation Wizard.

Outlook

This article gave an overview of the risks associated with high privileged service accounts and pointed out some ways to reduce these high privileges. In the next article we will discuss the topic of local administrator passwords how to assign individual administrator passwords on each system with the Local Administrator Password Solution (LAPS) and how to change them regularly.