Privilege escalation is the process of exploiting vulnerabilities or misconfigurations in systems to elevate privileges from one user to another, typically to a user with administrative or root access on a system. Successful privilege escalation allows attackers to increase their control over a system or group of systems that belong to a domain, giving them the ability to make administrative changes, exfiltrate data, modify or damage the operating system, and maintain access through persistence, such as registry edits or cron jobs.

From a penetration tester's perspective, privilege escalation is the next logical step after the successful exploitation of a system and is typically performed by bypassing or exploiting authentication and authorization systems, whose purpose is to segregate user accounts based on their permissions and role.

A typical approach would be to use an initial access or foothold on a system to gain access to resources and functionality that is beyond what the current user account permissions offer. This process is commonly referred to as getting root privileges on a system.

Before we can get started with the various privilege escalation techniques, we need to understand how user accounts and permissions are implemented in modern operating systems.

To better understand how to elevate privileges, we need to first understand how operating systems are designed in relation to user accounts and privilege.

Operating systems' authorizations are designed to handle multiple users with multiple roles and permissions. This segregation of roles is the primary factor behind the various user account implementation philosophies that are implemented in operating systems today.

This abstraction of user roles and permissions on a system is set up and facilitated by a system called a protection ring, as demonstrated in Figure 1.1. This specifies limits and enforces the functionality of users on a system and their corresponding access to resources.

As the name suggests, a protection ring is a hierarchical protection and segregation mechanism used to provide different levels of access to functionality and resources on a system. The various rings in the hierarchy represent layers of privilege within the operating system, as illustrated in the following screenshot:

Figure 1.1 – Protection ring

The rings in the hierarchy illustrated in Figure 1.1 are sorted and arranged from the most privileged (typically denoted by level 0) to the least privileged, where the least privileged is represented by the highest ring number. This segregation of privileges on a system leads to the adoption of two main roles, as follows:

• Privileged access: This is typically represented or assigned to the root or administrator account and provides complete access to all system commands and resources. The root or administrator account will typically have access to the following functionality:

  1. The ability to install, uninstall, and modify system software or binaries

  2. The ability to add, modify, or remove users and user groups

  3. The ability to create, access, modify, and delete any system or user data

  4. The ability to access and have control over all system hardware

  5. The ability to access network functionality and networking utilities

  6. The ability to create, manage, and kill system and user processes

• Unprivileged access: This is typically represented or assigned to non-root or standard user accounts and is limited to a specific set of privileges that are designed and tailored for standard user access on a system. It limits the user functionality to basic tasks and access of user data on the system. Non-root accounts will commonly have the following functionality:

  1. The ability to start and stop user processes and programs

  2. The ability to create, modify, and delete user data

  3. The ability to have access to network functionality

This segregation of permissions highlights the importance of privilege escalation for penetration testers or attackers as it offers total and unparalleled control over a system or, potentially, a group of systems if they can get "root" or administrative access on a system.

Given the nature of privilege escalation attacks in relation to user accounts and permissions, there are two main methods of performing privilege escalation that can be utilized by attackers based on their intentions and objectives, as follows:

• Horizontal privilege escalation
• Vertical privilege escalation

We will take a closer look at what they are in the next section.

Horizontal privilege escalation

Horizontal privilege escalation is the process of accessing the functionality or data of other user accounts on a system, as opposed to gaining access to accounts with administrative or root privileges. It primarily involves accessing or authorizing functionality on a system using accounts that are on the same user level of permissions, as opposed to user accounts that are higher up and that have more privileges and permissions.

Attackers or penetration testers would typically perform this type of privilege escalation attack if they were interested in accessing unprivileged user account data or in harvesting user account credentials or password hashes.

Scenario

The following screenshot illustrates a typical account setup on a computer, where we have two unprivileged users and one privileged user. In this case, the two unprivileged users are John and Mike, and the privileged user is Collin:

Figure 1.2 – Horizontal privilege escalation scenario

In this scenario, John is attempting to perform a typical horizontal privilege escalation attack by escalating his user account privileges to the account privileges of Mike. Note that John and Mike are on the same horizontal privilege level.

Figure 1.2 clearly outlines the sole objective of horizontal privilege escalation, the objective being to elevate privileges to user accounts that are on the same horizontal level as the user account performing the attack.

Vertical privilege escalation

Vertical privilege escalation is the process of exploiting a vulnerability in an operating system to gain root or administrative access on a system. This method is usually preferred by attackers and penetration testers as it offers the biggest payout given the permissions and functionality, as they now have total access and control over the system(s).

The following screenshot outlines a bottom-up approach to user account permissions and privileges, where the topmost account has the highest privileges, is the least accessible, and is typically assigned to system administrators. The lowest accounts are set up and configured to be used by standard users and services that require no administrative privileges as part of their daily tasks:

Figure 1.3 – Vertical privilege escalation

Figure 1.3 also illustrates a vertical approach to elevating privileges based on the user account and permissions for both Windows and Linux systems, the objective being to laterally move up the pecking order to the account with the highest privileges, therefore giving you complete access to the system.

Important note

Vertical privilege escalation may not solely emanate from the exploitation of a vulnerability within an operating system or service. It is common to find misconfigured systems and services that may allow non-administrative user accounts to run commands or binaries with administrative permissions. We will take a look at the various privilege escalation techniques in the upcoming chapters.

Scenario

The following screenshot illustrates a typical account setup on a computer, where we have two unprivileged users and one privileged user. In this case, the two unprivileged users are John and Mike, and the privileged user is Collin:

Figure 1.4 – Vertical privilege escalation scenario

For this scenario, Figure 1.4 illustrates a traditional vertical privilege escalation method where the user John is attempting to elevate privileges to the administrator account, which is Collin's account. If successful, John will get access to administrative privileges and will be able to access all user accounts and files, therefore giving him total access and control over the system. This scenario demonstrates the importance and potential impact of a successful vertical privilege escalation attack.

Now that we have an understanding of the two main privilege escalation methods and how they are orchestrated, we can begin taking a look at the various differences between privilege escalation on Windows and Linux.

Now that we have a general understanding of how user accounts and permissions are implemented and have looked at the two main methods of performing privilege escalation, we can begin taking a look at the differences between Linux and Windows in the context of privilege escalation attacks and at how their individual design and development philosophies affect the privilege escalation process.

This nuanced approach will give us clarity on the strengths and weaknesses of both operating systems and their corresponding kernels in relation to vulnerabilities and potential exploitation.

The following table outlines common potential attack vectors for both operating systems and the services that can be exploited to elevate privileges:

Table 1.1 – Common potential attack vectors

To fully understand the differences between the two operating systems in terms of potential vulnerabilities and attack vectors, we need to understand how they handle authentication and security as this will give us an idea of where the security pitfalls exist. It is important to note, however, that the security differences between Windows and Linux boil down to their unique design philosophy.

Windows security

Windows is a proprietary operating system that is owned and developed by the Microsoft Corporation and controls a majority of the PC market share at about 93%, which means that most companies are likely to be running Windows clients for their end users and/or Windows Server deployments for their critical infrastructure.

For this reason, Windows is more likely to be running on employee laptops and workstations as it has a much more user-centered design (UCD) and philosophy. In order to understand the privilege escalation process on Windows, we need to understand how Windows manages and maintains system security. In order to do this, we will need to take a closer look at various components that are responsible for managing and maintaining authentication and security on Windows.

User authentication

Authentication is the process of verifying the identity of a user who is trying to access a system or system resource.

Authentication on most modern operating systems is typically enforced through a username and password combination; however, operating systems have begun implementing additional layers of authentication, in addition to implementing stronger encryption algorithms for user passwords.

Passwords and password hashes are usually a target for penetration testers, and we will take a look at how to dump system passwords and hashes later in the book.

User authentication on Windows is handled by the Windows Logon (Winlogon) process and Security Account Manager (SAM). SAM is a database that is used to manage and store user accounts on Windows systems.

Modern releases of Windows utilize the New Technology LAN Manager 2 (NTLM2) encryption protocol for password hashing and encryption, which is significantly stronger than the LAN Manager (LM) encryption protocol present in older versions of Windows.

Authentication onto domains on Windows is typically facilitated by authentication protocols such as Kerberos.

User identification

User identification is used to uniquely identify users on a system and is also used to establish a system of accountability, as actions performed on a system can be tracked down to the user who made or performed them. Understanding how identification works and is implemented on Windows is extremely useful in the privilege escalation process to identify users on a system, along with their roles and groups.

The process of user identification on Windows utilizes a security identifier (SID) for identification. Each user and group has a unique SID that consists of the components outlined in the following screenshot:

Figure 1.5 – Sample Windows SID

The different parameters from the preceding SID are discussed as follows:

• SID String: S indicates that it's an SID string
• Revision: Always set to 1; this refers to the structure revision number
• Authority ID: Specifies who created or granted the SID, as follows:

  - Null: 0

  - World authority: 1

  - Local authority: 2

  - Creator authority: 3

  - Non-unique authority: 4

  - NT authority: 5

• Subauthority ID/actual ID: Unique ID for the user, or comprises the domain identifier
• RID: This stands for relative ID and is used in reference to other accounts to distinguish one user from another. Windows will have the following unique RIDs assigned to specific users. It is important to be able to identify privileged users based on their SID, as follows:

  - Administrator: 500

  - Guest user: 501

  - Domain administrator: 512

  - Domain computer: 515

You can enumerate the SIDs on a Windows system by running the following command in Command Prompt (CMD):

wmic useraccount get name,sid

This command will enumerate all user account SIDs on the system, as illustrated in the following screenshot. Pay close attention to the RIDs as they can be used to quickly identify administrator and guest accounts:

Figure 1.6 – Enumerating Windows SIDs

As displayed in Figure 1.6, we can identify user roles based on their RID, regardless of the account username. In this particular case, we have an administrator and guest account set up and they can be identified by their RID.

Access tokens

An access token is an object that describes and identifies the security context of a process or thread on a system. The access token is generated by the Winlogon process every time a user authenticates successfully, and includes the identity and privileges of the user account associated with the thread or process. This token is then attached to the initial process (typically the userinit.exe process), after which all child processes will inherit a copy of the access token from their creator and will run under the same access token.

On Windows, an access token will comprise the following elements:

• User SID
• Group SID
• Logon SID
• Privileges assigned to the user or the user's group
• Discretionary access control list (DACL) being used
• Source of the access token

We can list out the access token of a user by running the following command in the CMD:

Whoami /priv

If the user is unprivileged, the access token will be restricted, as outlined in the following screenshot:

Figure 1.7 – Restricted access token

It is important to note that the user highlighted in Figure 1.7 has administrative privileges; however, the cmd.exe process uses an access token that restricts privileges. If we run cmd.exe as an administrator, the user's access token will be listed with all privileges, as outlined in the following screenshot:

Figure 1.8 – Privileged access token

Access tokens can be leveraged during the privilege escalation process through attacks such as primary access token manipulation attacks, which involve tricking a system into believing that a process belongs to a different user from the one who started the process. We will learn how to utilize this attack vector to escalate our privileges later in the book.

Linux security

Linux is a free and open source operating system that comprises the Linux kernel, which was developed by Linus Torvalds, and the GNU's Not Unix (GNU) toolkit, which is a collection of software and utilities that was originally started and developed by Richard Stallman. This combination of open source projects is what makes up the Linux operating system as a whole, and it is commonly referred to as GNU/Linux.

Typically, most individuals and companies are likely to be running Windows clients and will be using Linux for their critical infrastructure—for instance, mail servers, databases, web servers, and intrusion detection systems (IDSes). Given the nature and deployment of Linux servers in organizations, attacks will be much more likely to severely affect a company and cause major disruption.

User authentication

User account details on Linux are stored in a /etc/passwd file. This file contains the user account username, the user ID (UID), an encrypted password, a group ID (GID), and personal user information.

This file can be accessed by all users on the system, which means that any user on the system can retrieve the password hashes of other users on the system. This makes the hash-dumping process on Linux much more straightforward and opens the door to potential password-cracking attacks. Most older Linux distributions utilized the Message Digest Algorithm 5 (MD5) hashing algorithm, which is much easier to crack, and as a result, most newer distributions have begun utilizing and implementing the Secure Hash Algorithm 256 (SHA-256) encryption protocol, therefore making it much more difficult to crack the hashes.

Identification

User authentication on Linux is facilitated through the use of a username that corresponds to a unique UID, comprising a numeric value that is automatically assigned or manually assigned by a system administrator. The root account on Linux will always have a UID of 0.

This user information, along with the hashed user passwords, is stored in the /etc/passwd file.

Access tokens

Access tokens on Linux work in a similar way to how they work on Windows but are stored in memory (random-access memory, or RAM) and attached to processes when initialized.

The access token on Linux will contain the following information:

• UID of the user account
• GID/GIDs of the groups that the user is a member of
• User privileges
• Primary group UID
• Access control list (ACL) entries

Now that we have an understanding of the various authentication and security components used on Windows and Linux, we can take a look at the various types of privilege escalation attack and how they exploit the aforementioned security mechanisms.

We can now explore the most common privilege escalation attacks and how they work. The objective is to get a basic picture of the types of privilege escalation attack available and to understand how they are exploited.

We will take a look at how to exploit these vulnerabilities in depth on both Windows and Linux systems in the upcoming chapters.

Kernel exploits

Kernel exploits are programs or binaries that affect both Windows and Linux and are designed to exploit vulnerabilities in the underlying kernel, to execute arbitrary code with elevated or "root" permissions.

The exploitation process is multi-faceted and requires a good amount of enumeration in order to determine the operating system version and installed patches or hotfixes, and consequently whether it is affected by any kernel exploits, after which the kernel exploit code can be retrieved through various exploit repositories such as exploit-db. The exploit code should then be inspected and customized based on the required parameters and functionality. After customization, the code can be compiled into a binary and transferred over to the target for execution. In some cases, the exploit code will need to be downloaded and compiled on the target if it relies on certain dependencies.

After successful compilation and execution of the binary, the kernel exploit will grant the attacker "root" access on the target system in the form of a shell prompt, where they can run commands on the system with "root" privileges.

In many cases, precompiled kernel exploits for Windows already exist online and can be downloaded and executed directly, therefore avoiding the compilation process altogether. However, it is very important to inspect and analyze the exploit code before compiling it, as exploits could contain malicious code or payloads.

Important note

Kernel exploits are extremely powerful; however, they can cause system crashes and kernel panics that can hinder the privilege escalation process and can cause damage to the system.

Exploiting SUID binaries

SUID is an inbuilt Linux feature that allows users to execute binaries and files with the permissions of other users.

This feature is commonly used to allow non-root accounts to run system utilities and binaries with root permissions. You can set the program or utility SUID permission with the owner as "root." This will allow the program or utility to run with "root" privileges whenever a non-root user executes it. Attackers can exploit or take advantage of SUID misconfigurations and run arbitrary commands as root.

For example, programs or binaries that allow the execution of arbitrary commands such as vim should not have their SUID owner set as "root," as non-root users can leverage the command execution functionality within vim to run commands with "root."

Exploiting vulnerable services and permissions

Services offer the largest threat surface for attackers, given the variability and diversity of programs and services that can be found running on Windows and Linux systems.

Attackers will typically aim to identify misconfigured or vulnerable services and programs that could facilitate the escalation of privileges. For example, on Linux systems, attackers will try to identify and exploit misconfigurations with cron jobs and leverage the functionality to execute arbitrary code or malicious binaries.

Exploiting vulnerable or insecure services on Windows typically involves embedding a payload in a service with administrative privileges. When the service is executed, it executes a payload with the administrative privileges, therefore allowing the binary to execute commands with "root" privileges.

Insecure credentials

This technique involves searching for insecure credentials that have been stored on a system by users or by carrying out a process of cracking weak user credentials. Many users—and even system administrators—note down passwords in cleartext in documents, spreadsheets, and configuration files for various service accounts. These files can be located by running specialized search queries with various command-line utilities.

An example of this is the use of the find command-line utility on Linux to locate files with specific extensions and filenames.

Exploiting SUDO

Attackers will usually target users who have SUDO privileges. SUDO allows users to run commands as another user, typically the root user.

SUDO privileges are usually configured manually by administrators, which leaves the door open to potential misconfigurations. For example, an administrator can assign SUDO permissions to a non-root user for certain command-line utilities (such as find or vim) that can run shell commands or arbitrary code.

This can be leveraged by attackers to run arbitrary code or execute commands with "root" privileges.

Important note

SUDO is a Linux command and permission set that allows users to run commands or programs with superuser or "root" privileges.

These are just some of the privilege escalation attacks and techniques that can be used on both Windows and Linux systems. We will be taking a look at how to use these techniques in detail in the upcoming chapters.

This chapter introduced you to the privilege escalation process, explained how privileges and user accounts are implemented in modern operating systems, and looked at the differences between privilege escalation on Windows and Linux systems. It also highlighted the most common privilege escalation techniques and explained how they can be exploited.

You should now have a good understanding of the privilege escalation process, how permissions and privileges are implemented, and the various penetration testing techniques that are used on both Windows and Linux.

In the next chapter, we'll get started with setting up our virtual environment and preparing our penetration-testing distribution. We will also look at the various tools and frameworks we will be utilizing to enhance and optimize the privilege escalation process.