2. Privileges – Privileged Attack Vectors: Building Effective Cyber-Defense Strategies to Protect Organizations

© Morey J. Haber 2020
M. J. HaberPrivileged Attack Vectorshttps://doi.org/10.1007/978-1-4842-5914-6_2

2. Privileges

Morey J. Haber1 
Heathrow, FL, USA
Today, privileges based on credentials are one of the lowest-hanging fruits in the attack chain. They are currently the easiest method for a threat actor to own a resource and, ultimately, the entire environment. These threats include
  1. 1.

    Insiders having excessive and unmonitored access to accounts, opening the potential for misuse and abuse

  2. 2.

    Insiders that have had their accounts compromised through successful phishing, social engineering, or other tactics

  3. 3.

    Accounts that have been compromised as the result of weak credentials, passwords, devices, and application models, allowing attackers to compromise systems and obtain privileges for malicious activity

To recognize how privileges can be used as a successful attack vector, a better understanding of the definition of privileges needs to be established above what has been previously discussed. In plain English, a privilege is a special right or an advantage. It is an elevation above the normal and not a setting or permission given to the masses. An example is the relationship to education. “Education is a right, not a privilege.”1 Everyone has the right to education and, thus, in the information technology world, is analogous to a Standard User. A standard user has the same basic rights as almost everyone else; they are not privileged. Therefore, in a typical organization, standard users have rights that are global to all authenticated users—just like an education. As these user accounts are created and provisioned, they are granted these standard rights. This could be basic access to company-wide applications, the ability to access the Internet or intranet, or productivity applications, such as email. A privileged user has rights above that. This may include the ability to install other software, change settings within their local machine or application, or perform other routine tasks like adding a new printer. This does not mean they are an administrator. It means they have been granted privileges, at a granular level, above the baseline of Standard User to perform these tasks. This granularity can have as many levels as an organization deems necessary based on the roles and job responsibilities for its users. The most basic interpretation contains only two levels:
  1. 1.

    Standard User: Shared rights granted to all users for trusted tasks.

  2. 2.

    Administrator: A broad set of privileged rights granted for managing all aspects of a system and its resources. This includes installing software, managing configuration settings, applying patches, managing users, and so on.

However, most organizations will define privileges across five fundamental levels:
  1. 1.

    No Access: This means you do not have a user account, or your account has been disabled or deleted. This is the denial of any form of privileged access, even anonymously.

  2. 2.

    Guest: Restricted access and rights below a standard user. Often, this is associated with anonymous access.

  3. 3.

    Standard User: Shared rights granted to all users for trusted tasks.

  4. 4.

    Power User: A power user has all the entitlements of a standard user, plus additional granular privileges to perform specific tasks. They are not an administrator or root, but have been trusted to perform specific tasks that are typically associated with administrators.

  5. 5.

    Administrator: Authorized permissions (in the form of privileges) to alter or abuse the asset’s runtime, configuration, settings, managed users, and installed software and patches. This can also be further classified into local administrator rights and domain administrative rights affecting more than one resource.


While this perspective of privileges is at a macro-user level, it is essential to understand the micro-level of permissions down to the token and file to formulate a proper defense. It is myopic to consider privileges are only a part of the application you are executing. Privileges must be built into the operating system, file system, application, database, hypervisor, cloud management platform, and even network via segmentation to be effective for a user and application-to-application communications. This is true if the authentication is granted by any mechanism ranging from a username and password to a certificate key pair. The resource’s interpretation of the privileges cannot be just at any one layer to be truly effective. It must be available across the entire stack. To that end, let’s explore privileges based on each level, excluding no access.

Guest Users

As a Guest User, your privileges are strictly limited to specific functions and tasks you can perform. In many organizations, guests are restricted to isolated network segments with basic access—perhaps access to the Internet for visiting vendors. If these unmanaged computers are, or become, compromised, the risk is mitigated by limiting access to the organization’s resources, especially via lateral movement. For example, a network scan from a compromised guest machine will not (or at least should not) provide the attacker direct access to corporate systems and data, regardless of whether they are connected via Ethernet or wirelessly.

Standard Users

As a Standard User, you have select privileges beyond that of a Guest to perform additional tasks and to fulfill the mission that is associated with your job and role. While organizations may forego implementing Guest Users, it is typical to have granular levels between a Standard User and a Full Administrator. These are often referred to as power users. Typical organizations may have 100s or 1000s of different standard user roles designed to balance access and efficiency with risk. Each role has been granted access to specific systems, applications, resources, and data required for their specific job. In many cases, a user may be a member of multiple groups, depending on their specific job requirements. For example, low-access roles (also called basic roles, basic entitlements, and birth rights when discussing identity governance) are typically provided to each organizational user (employee, contractor) to provide basic access. As an example, this could provide access to email and the corporate intranet. Next would be specific roles that would add more access based on the job function or role itself. See Figure 2-1 for a very basic example of a role hierarchy in a typical environment.
Figure 2-1

Example of a Role Hierarchy in a Typical Environment

In this example, the banding and nesting of granular permissions within business roles may allow specific users access to a web server, but not access to a database, or vice versa. From the perspective of a threat actor, compromising accounts with elevated privileged rights is typically the target as these credentials are the ones that have access to sought-after systems and data. As a rule of thumb, the more administrative functions you are required to perform, the more administrative privileges you have. In addition, as you go up the hierarchy from sole contributor to executive, the fewer privileges you should have. Unfortunately, in many organizations, that is not always the case, and it is bad security practice when navigating on your PAM journey.

With this in mind, malicious activity does not require full-domain administrative or root rights (even though that reduces technical barriers and makes it easier for them to conduct nefarious activity). For example, if the user is a manufacturing floor worker, their potential privileges are limited by their job role (barring a vulnerability and successful exploit). If the target user is an information technology administrator, such as a server administrator, desktop administrator, database administrator, or application administrator, the associated privilege risk will be higher as these employees have been granted additional access as defined by their role. This makes them desirable targets for a threat actor. Take, for example, a threat actor who wants to gain access to a corporate database or file system with sensitive unstructured data (see Figure 2-2).
Figure 2-2

Example of an Attacker Who Wants to Gain Access to a Corporate Database or File System with Sensitive Data

Does the threat actor:
  1. 1.

    Attempt to directly attack the hardened database or system housing the sensitive data. This is a system that is likely patched and monitored and incorporates advanced threat detection and attack shielding technologies due to its sensitivity and regulatory compliance requirements.

  2. 2.

    Use a phishing attack to compromise the system/database administrator and steal those credentials to log directly into the target system, impersonating a legitimate user.


Having privileged access to an application, its database, or supporting file system is all that is needed to extract information once an internal beachhead has been established. This attack vector can also potentially allow the threat actor to execute commands, perform lateral movement, and exfiltrate the data regardless of whether they are an external or internal threat.

Additionally, many organizations grant more privileges than are required for a specific job, which leads to increased risk from both hackers and attackers. For example, many organizations still allow users to have administrative control over their desktops simply for convenience or due to legacy applications that require administrative rights.

It is also important to note that recent attacks are beginning to focus on nontraditional assets that may lack the flexibility and control required in today’s sophisticated threat environment. With some systems, the access options are very Boolean. You have access, or you do not. When you do, you are an administrator and have complete control. This is primarily true for consumer devices that do not have any concept of role-based access, but it’s also true for many Internet of Things (IoT) devices, legacy systems, and even next-generation technologies used for manufacturing, automation, and robotic control.

Power User

A power user is an elevated use case of a standard user that engages with applications and resources that need unique, sensitive, or advanced features that are not entitled to be used by the average standard user. A power user may not have extensive technical knowledge of the resources they operate, but have the competence or role to operate within privileged guidelines to perform specific tasks.

Also, within an organization, a power user may be a formal role given to an individual, and they may be considered the specialist for a particular software, role, or resource. Often, these are people who are trained to perform advanced functions above their typical job role, and, thus, given privileges to do so. Power users represent the universe between standard users and full-blown administrators based on explicit privileges granted to perform specific tasks. Again, they are not administrators, but based on the privileges they have been granted, they can be a source of privileged attack vectors. This is especially true if they are overprovisioned, unmonitored, or the entitlements they have been granted abused since their privileges allow them access to potentially sensitive tasks.

Finally, some common roles that are associated with power users are typically found within development, help desk staff, application and database administrators (even though they are not granted administrative or root privileges), and even engineering.


As an Administrator or Root User, you “own” the system and all its resources. All functions, tasks, and capabilities are potentially within your control, and even if technology is deployed to block an administrator, being an administrator means there is still likely a way, or backdoor, around the restrictions. This leads to the premise that once you are an administrator, the security game is over. An administrator can circumvent any protection designed to protect against an administrator, even if the results are destructive to the processes themselves.

Obtaining administrator or root access represents privileged access that is considered the crown jewels to a threat actor. Once the threat actor has root access and can operate undetected, then any system, application, or data is potentially within their reach. Gaining privileges is the ultimate attack vector for breaching an organization, government, or even end-user–based computing device. Again, in this case, organizations tend to grant too many unmanaged administrator privileges, which leads to significant risk posed by threat actors and insiders. One of the primary use cases for PAM is to remove these unnecessary privileges and only grant the ones that are explicitly needed, and just for the moments in time they are required. This will be discussed in more detail later in the book.

Identity Management

The process of defining, managing, and assigning these roles to ensure that the “right” people have the “right” access at the “right” time is known as identity and access management (IAM). It is a specific solution family within identity governance. These “rights,” including role-based access and permissions, are called entitlements. Privileged access management (PAM) typically complements traditional IAM processes and solutions with additional layers of control and auditing for “privileged” accounts. These are the accounts that pose the greatest risk to the organization. Figure 2-3 shows the relationship of PAM to identity governance as defined by the Identity Defined Security Alliance (IDSA).
Figure 2-3

Identity Defined Security Alliance Framework (IDSA), 2019

To better understand the scope of privilege risks, please reference Figure 2-4. In many situations, a lack of visibility and control over privileged accounts, users, and assets could leave you exposed to a damaging data breach. That visibility often begins with a simple discovery exercise through all assets within an organization. Ergo, let’s first take a look at where these privileged accounts exist. Then, once we get a complete picture of the scope of the challenge, we can discuss some strategies to address it.
Figure 2-4

Lack of Visibility and Control Could Lead to a Data Breach

Although this perspective of privileges is at a macro-user level (identity management), it is imperative to understand the micro-level of permissions down to the token and file to formulate a proper defense. It is again a mistake to consider privileges are only a part of the application you are executing. Privileges must be built into the operating system, file system, application, and even network via segmentation (often zero trust) to be effective for a user and application-to-application communications. The resource interpretation of the privileges cannot be just at any one layer to be truly effective. Thus, identity management only provides access to the resource by scope or role. In contrast, privileged access management provides the granular permissions needed when the operating system or application is incapable of providing these privileges itself. It is fair to state that PAM is a subset of IAM and an extension to protect privileges at every level.


For the sake of definitions, and commonly misused within the industry, an identity is simply a carbon-based life form (and a quick shout-out to all my fellow Star Trek fans. Spoiler alert—Decker and V’ger created the Borg, and it was all Kirk’s fault for allowing it to happen). It is any human being or user that interacts with resources, from applications to operating systems. This includes physical and electronic access and is a convenient way of saying I am a person. “I think; therefore, I am,” and I have an identity. A user should only have a single identity.

In addition, in modern computing environments, an identity can also be assigned to a piece of information technology. These are typically devices like mail robots or other technology that interacts with the real world in a physical nature. Electronic identities are not software or applications, but rather devices that can take on human traits. It is important to note that any technology assigned an identity can have multiple accounts, just like a human identity, but they also have a unique attribute to designate its owner. That is the human identity (or group) that is responsible for the electronic identity by reference of an owner tag.

For human identities, security best practices become blurred when people assume different names, including having maiden names, and they may have duplicate identities referenced electronically in an organization. To be clearer, they still have only one identity, but may have electronic instantiations to multiple identities, which should not be confused with having multiple accounts. Organizations should only have one identity for a person, like their social security number (which is a bad practice due to personally identifiable information), or preferably an employee number—one person, one identity, and one electronic reference linking them. Then, they can have multiple accounts. As an additional security best practice, the number of accounts should be minimized and easily linkable back to the proper identity.


An account is an electronic representation of an identity or reference for a set of permissions and privileges needed for an application or resource to connect or operate within the confines of the system. While the definition of an account is evident for an identity, it can take on a variety of forms when used electronically for services, impersonations, and application-to-application functions. Accounts can have a one-to-many relationship with identities, be defined locally, grouped, or managed via directory services. Accounts can have role-based access applied at the account level, group level, within a directory, and these can range from disabled (denied access) to privileged accounts such as root, local administrator, or domain admin. The level of privileges and role-based access is dependent on the security model of the system implementing them and can vary significantly from one implementation to another.

Therefore, accounts linked to identities are how we gain access to information technology resources. For technology itself, accounts are a vehicle to authorize their usage, provide development automation, and supply operational parameters. Too much privilege given to any type of account can introduce risk, and accounts can literally be named and referenced to almost anything, and are subject to limitations within any system. For example, some systems may not allow the renaming of an administrator account even though it is a security best practice to do so. Accounts are literally a reference field to provide authentication, and an account may or may not have a password or key. When a password is assigned, regardless of its strength, type, or security, it becomes a credential.


A credential is an account with an associated password, passcode, certificate, or other type of potentially secret key. Credentials can have more than one security mechanism assigned for dual or multi-factor authentication, or be basic Guest credentials for anyone to access—without the need for a secret key or by using a common, known key. Credentials are just a mere representation of the account-password combination needed for authentication. They are, nonetheless, the crown jewels for any threat actor to begin an escalation of privileges.

When an attacker indicates that they have “hacked” an account, what they mean is that they have hacked the credentials associated with the account. Literally hacking an account would only yield a username. Both the username and password are needed to compromise a system, and potentially its data, successfully. Thus, for the sake of simplicity in the remainder of this book, hacking an account means the same thing as hacking credentials. It is difficult enough to manage privileges in an environment rather than worrying about the semantics used every day in describing the threat. Security professionals and the press will probably never change in saying one million accounts were compromised, when, in fact, one million credentials were compromised. See the difference? (And another shout-out to sci-fi fans, what credentials did R2-D2 use to hack the Death Star?)

Default Credentials

Whenever you purchase or license a new resource, whether it is a device, application, or even a cloud resource, it comes with a default credential scheme used for initial access and configuration. The resource is typically in a pristine state, not fully hardened, and vulnerable to a variety of password attacks, especially to the default root or administrator account that could own the entire system. If this account is compromised, a wide range of persistent privileged attacks could occur by a threat actor and go undetected for years since the defaults governing the solution have not been managed and, more consequently, not maintained or monitored. These default credentials are required so that an organization can consistently perform the initial configuration. Logically, using security best practices, the default credentials should be changed, but many times they are not. This exposes these default accounts as a privileged attack vector. Today, manufacturers have six choices for passwords when they ship a device, application, or other resource:
  1. 1.

    Anonymous Access: Full, unrestricted, default access with no credentials

  2. 2.

    Blank Password: Default username, but no password

  3. 3.

    Default Password: Default credentials with predictable username and password

  4. 4.

    Default Randomized Password: Default username with a fully randomized password

  5. 5.

    Pattern-Generated Password: Default username with predictable password

  6. 6.

    Forced Password Change: Default credentials with a forced password change required before normal operation


If the default passwords are not changed, it’s just a matter of time before the device, application, or resource will be owned. These are the basics for privileged management: changing the predictable or easily obtained to something that requires knowledge to access.

Note that the California Consumer Privacy Act implemented in 2020 requires scenarios 4 and 6 to be implemented on all new consumer devices to prevent privileged attacks. All other methods are now considered illegal for consumer device sales. This does not necessarily hold true for devices targeting businesses or noncommercial sales, and it is still unclear how adoption will be enforced across all network-enabled devices. In addition, even though this is a California state law, all geolocations will benefit from this legislation since it is highly unlikely device manufacturers will produce two versions targeting the rest of the world and the fifth largest economy in the world, the state of California.

Anonymous Access

Anonymous access is simple and absolute. No authentication is needed to begin the setup of the resource, including advanced settings that may be used to secure the asset from future attacks. While this method seems completely ludicrous in today’s security climate, it is often the only way to configure a resource for the first time. Consider the purchase of a new cell phone or mainstream tablet with either iOS or Android. Its initial configuration allows for anonymous access to set up Wi-Fi. The initial user can connect to any Wi-Fi network, including ones for which they may have WPA2 keys. This is typically not required to complete the configuration, but if misconfigured, initially or not, it could lead to a man-in-the-middle attack if the setup is not performed in a secure location.

In addition, the primary administrator user account on the device can be set with a null password, basically allowing full, unrestricted access to the device at any time. This even holds true for devices that have biometrics, like facial identification or fingerprint recognition. These devices can be configured to not enforce a password even though it is recommended, and it may be required later to access corporate resources via a mobile device management solution or management profile. If the device was compromised in the first place, adding these restrictions later is a moot point.

What makes anonymous access an absolutely horrible security threat are the instances when it is not disabled or changed after the initial configuration. Surprisingly, there are plenty of information technology resources that only support anonymous access. These include, but are not limited to, SCADA sensors like thermocouples, children’s IoT toys, and digital home assistants (after their configuration) that rely on voice commands. In the end, these are devices that have minimal-to-no programmatic concept of accounts or role-based access, and every user that interacts with the device has the same level of privileges. To that point, Figure 2-5 displays how even a file share can be granted anonymous access for anyone, at any time, to gain access.
Figure 2-5

Anonymous Option for Adding an NFS Share

Blank Password

Blank passwords are commonly used in resources that have multiple accounts but have a null password by default. The security and initial configuration of the resource may require that a password be assigned; however, many technologies, including older databases, do not even prompt for a password assignment after the solution is installed and operating. The risks are apparent. Accounts are present, not properly configured, and, depending on the privileges, are easy targets for a threat actor. Figure 2-6 illustrates this for a website where the credentials have not been set.
Figure 2-6

No Account or Password Settings

Blank passwords (credentials) are not anonymous accounts but rather credentials that have not been assigned and, in many cases, just a bad misconfiguration that should be mitigated when hardening the device. People commonly confuse accounts that have blank passwords with anonymous access. However, two significant differences should be well understood. With anonymous access, the identity of the user is not considered, and such access is typically reserved for low-risk activities. With an account with a blank password, the identity of the user is considered, but the security of the authentication process is diminished, usually an oversight that creates undue risk. The most common, and widely used, blank password solutions are systems that support Guest accounts. Anonymous access is independent of whether the guest account is enabled and is typically reserved for all to access. My point is that unauthenticated access is typically purposeful and required for operations, while a blank password is usually an indicator of a privilege vulnerability and bad configuration.

Default Password

For many years, manufacturers released solutions with default passwords. Every model series of the device had a unique password, and, for some manufacturers, the default password is the same for every new resource they produce. Although this is a common practice, it is a glaring security issue. There are volumes of lists publicly accessible on the Internet of these default passwords for every vendor, and all a threat actor needs to do is try them. Also, regulatory mandates (discussed later) prohibit the existence of default passwords (of any type) to be used in production due to the risk. These devices are susceptible to an attack as soon as they are connected to a network or the Internet. This is particularly dangerous if the device is not properly configured and still has the default credential after the resource is placed in production. However, some devices may not actually allow for the default password to be changed. This represents a privileged attack vector that is extremely vulnerable, just like anonymous or blank password access to the root account.

However, blank passwords (as defaults) are not just a threat to endpoints and networking devices. In many cases, application vendors will place the onus of implementing security controls on the application users and developers. For example, MongoDB is a popular NoSQL database used by organizations to perform big data and heavy analytics workloads. The default installation of MongoDB on older releases does not actually require authentication to access the database. This resulted in a widespread attack in early 2017 in which application and database administrators were not enabling authentication to the database. To make matters worse, many of these databases were directly accessible to the Internet. For these reasons, the importance of communicating security best practices at all levels of the organizations, including secured coding by the development and application teams, is critical. Figures 2-7 and 2-8 illustrate real-world, commercially available technologies that have poor default password implementations.
Figure 2-7

Home-Based Router with Actual Text in the User Interface Stating the Default Password

Figure 2-8

Commercial-Based Server Solution with an Option to Keep Default Credentials

Default Randomized Password

In today’s world, the most secure default password is one that is unique and randomized for every single resource that is produced, licensed, or sold. This password needs to be securely conveyed to the administrator or organization for the initial setup and should be changed upon the initial configuration. Unfortunately, some manufacturers have taken this concept to a level that makes the devices unsecure if physical access to the device is available. Along with the serial number, these vendors have printed the default passwords on the device for anyone to retrieve (see Figure 2-9). A simple press and hold of the reset button restores the password to the default and, depending on the device, the configuration too. Once reset, a threat actor now has access to compromise the asset. Mitigation for this type of threat is relatively simple. Copy (photo, scan, or type) the default password documented on the resource, securely store it, and then destroy, mask, or remove the label. In addition, physical access to any device that allows for a soft or hard reset, or password reset remotely, should be secured to prevent this threat. Most compliance regulations mandate this as well. Randomized passwords are currently one of the most secure methods to distribute default passwords, but they also may present risks depending on how that password is initially distributed.
Figure 2-9

Factory Serial Number with Weak Default Credentials and Randomized SSID Password

Pattern-Generated Passwords

Identity governance requires sound, documented, and repeatable processes for onboarding new users, creating new identities and accounts, deleting identities and accounts, providing certification reports for access, and providing access for them to perform their jobs. When not managed properly, these accounts can create a significant security risk.

Have you ever worked for a company where an automated system creates the default login account and password based on something that everyone knows—like your name? Often, this is how an IT/help desk sets up the default access for new employees or reset passwords upon some form of authentication or login failure. For them, it is easy to document, potentially automated, and can be similarly communicated to users as a password for them to gain access.

For example: If I have a new user named “John Titor” (and, before I go any further, I am not John Titor,2 the time traveler from 2036—sorry to disappoint you). I may have an algorithm that generated the login account and credentials by extracting components of his name. Here my provisioning process is to create the login account using the “first initial of his first name + last name” with a default password of “New” + “first initial first name” + “first initial last name” + “!!!2036$”. This paradigm results in the following account:
  • Login Account: JTitor

  • Password: NewJT!!!2036$

To successfully compromise this account, all I need to know is the new user’s name and the algorithm to define the default password. And if I am an insider who went through this process, I would have a pretty good idea of what it is. Now, you may indicate that this is not really a risk, as these accounts would typically be set to require a password change upon first login, and that is true. However, there are three things to consider:
  1. 1.

    This account would certainly be exposed from the time it is created and the hacker changed the password upon login to the time the new employee realized that they could not access their pre-created account and has their password reset by the IT team.

  2. 2.

    In some cases, the organization may not enforce “change after first logon” for these default passwords, and the employee may continue to use it!

  3. 3.

    The process may be used to reset locked or disabled accounts, making the passwords highly predictable.

Of course, to overcome these issues, more secure best practices can be implemented to reduce these risks, including the enforcement of “change password on next login” and multi-factor authentication. Figure 2-10 shows how to enforce a password reset during the next logon. This should be used regardless of whether or not you use a pattern-generated password to keep the password secured only to the account and the appropriate user.
Figure 2-10

Force a Password Reset During the Next Logon

Forced Password Change

Forced password changes are a natural extension to forcing a password reset upon the next login. The major difference is that this setting is enforced upon the initial setup of the device or application, and the product will not function correctly until it is completed. Unfortunately, even though this has the best of intentions to protect against default credential attacks, it does not:
  1. 1.

    Have a mechanism for more than one device to share or reuse the same credentials. This makes them more susceptible to lateral movement, or other privileged attack vectors discussed later.

  2. 2.

    Have a mechanism to enforce password complexity, common passwords, or other password mistakes that can be used as attack vectors.

  3. 3.

    Provide a mechanism to centrally manage credentials upon an initial forced change. In other words, there will always be a local administrative account, potentially not under management, that can be leveraged as a backdoor.