The Blurring Line Between Privileged and Non-Privileged Users

July 28, 2020 Corey O'Connor

Privileged Access Management

“Identity truly  is the new perimeter” was one of the big topics  at Impact Live. This is because  organizations are dealing with a new set of operational and security challenges related to introducing more endpoints and  the reality of their workforce operating entirely remote for the indefinite future.

Consider this: in today’s world, to avoid user friction and not slow down productivity, it’s possible to elevate a non-privileged account (i.e. a standard business user on a Windows machine) to enable privileged access, so it isn’t enough to just consider the accounts that been granted privileges – they must be consistently monitored and managed. This creates a growing need to have controls in place to secure all identities – human and non-human – that have the potential to gain privileged access to critical systems and assets. It’s important to consider that this heightened level of access is exactly what attackers seek in their mission to disrupt a business or steal sensitive information.

At a deep technical level, let’s review three specific examples where a traditionally non-privileged user can gain privileged access.

Example 1: The Backup Administrator

The lifeblood of every organization is the data that it possesses. Whether its customer data, intellectual property, or financial reports and statements there needs to be a strategy in place for determining how that data is defined and managed for back up. Backup and recovery systems will help prevent data loss during an event and the backup admin is ultimately responsible for this inherently challenging task.

A backup admin, who only has access to permissions specifically pertaining to Backup and Recovery (BRS) systems, has the ability to take the archive and restore the NTDS.Dit file, which is a flat file representation of the Active Directory (AD) that is used in normal cases for system state recoveries. This file contains all AD objects, including accounts, passwords, keys and certificates, to name just a few.

Once the NTDS.Dit file has been extracted from the backup archive, a nefarious insider can then use tools like Mimikatz to extract all the hashes for all accounts in AD, which would include the KRBTGT account. The KRBTGT is essentially the signing account for all objects in AD and the main target for a DCSync attack. Once the KRBTGT is compromised, the attacker can then take that information back to the live environment and use the exported/cracked hashes to compromise that environment.

One of the worst aspects of this attack is that the attacker has all the time in the world to perform these activities undetected, since they can perform them outside of the corporate network where intrusion detection software or other security technology would not be a factor.

Figure 1. The malicious backup admin restores the NTDS.dit file from the backup server. From there they can pull it offline to crack the hashes (outside of the scope of any counter measure) and then bring it to the live environment.

If interested in learning more, you can see Keberoasting and other similar advanced attacks in action by attending the CyberArk PAM Summer Series.

Example 2: The Service Account

A service account is a non-human account that is often times used by an application or service to interact with the operating system to perform things like scheduled tasks. A big concern from a security perspective is the fact that the majority of organizations never perform an audit on their service accounts. Let’s look at the svc_sql account, which is created during an install of Microsoft SQL Server.

In this example, we will assume the attack originates from the outside and the attacker has gained an initial foothold into the organization from a compromised endpoint. To obtain credentials tied to the organization’s service accounts, the attacker can perform Kerberoasting, which takes advantage of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs). After the attacker dumps the Kerberoasting payload, a scan can be performed to determine the vulnerability of the service accounts in AD. Once enumerated, the attack would be performed on a specific account, which will return the hash of the SPN that was selected.

Once the hash has been obtained, it can be cracked utilizing the John the Ripper tool, returning the clear text value of the password. If no additional preventative measures have been taken to lock down interactive logons and place service accounts in an authorized hosts list, the attacker could interactively log into other hosts on the network as the service account. In this example, the attacker could now very easily compromise the Domain Controller by logging in as the svc_sql account. Game over.

Figure 2. [1] A TGT is requested with the NTLM hash provided; [2] The TGT is received with the encrypted KRBTGT hash; [3] TGS is requested for the server and is presented with the TGT; [4] The TGS encrypted with the server account hash is received by the server; [5] The TGS encrypted with the server account is presented for service and [6] it’s used when manual authentication is required.
Example 3: Dynamic Link Libraries (DLL)

DLLs are files loaded by Windows binaries that contain additional functionality that can be used to make programming within the Windows environment easier. Whenever an executable within Windows opens up or runs in some way, it will frequently attempt to load a DLL within the Windows environment.

Often times, the binary can attempt to load DLL’s that don’t exist due to a variety of reasons, such as older code not being removed. If this occurs within a directory that’s writeable by a non-privileged user and that binary is run as part of a service under an elevated context, an attacker can easily create a malicious DLL in its place, store it in that writeable directory and have it execute under the elevated context.

Moreover, even if the DLL does exist, an attacker can still hijack the execution flow. For example, if safe DLL search mode is enabled and the DLL that the binary is calling does not exist within its current directory, then, as long as the current directory is writeable, an attacker can install a malicious DLL there and have it run the next time the elevated service or program attempts to run.

Figure 3. An attacker places a malicious DLL within the executable’s own directory and the exe finds the malicious DLL first and loads that one, never reaching the legitimate one in the system directory.

From here, the attacker can elevate to whatever ‘context’ the user that executed the process was – in most cases this is the admin on the local machine. Not only was the account or permissions stolen, but the attacker could perform malicious activity under the guise of that admin. They can execute any arbitrary code they’d like to steal or delete data or establish persistence on the machine to monitor activities and perform reconnaissance. Local admin privileges on a machine also gives the attacker the ability to dump local passwords from the Local Security Authority Subsystem Service (LSASS), again using tools like Mimikatz to find additional domain credentials that could be used to perform lateral movement across the network.

Identity Security is the Future

CyberArk’s mission for Identity Security is to provide a SaaS-based Identity Security platform that offers secure access to any user accessing any application or system (from hybrid to multi-cloud) from anywhere and using any device.​ ​All types of access will be provided on a unified platform, leveraging artificial intelligence to automatically apply the needed privileged access security controls to each session based on the level of access that is required and the associated risk of the session.​

CyberArk’s investment in continuous innovation drives enhanced privileged access management capabilities across our portfolio, such as session isolation, session recording, continuous authentication and just-in-time access to the wider range of identities – whenever privileged access is required.

Want More From Impact Live?

Missed the event? No problem. Sign up for Impact Live on-demand to view all the recorded keynotes, breakout sessions and all other content from the original event.

 Many thanks to Len Noe, Asaf Hecht and Arash Parsa from CyberArk for their contributions to this blog.

Previous Article
7 Best Practices for Securely Enabling Remote Work
7 Best Practices for Securely Enabling Remote Work

At Impact Live 2020 we spent a lot of time discussing strategies for maintaining a strong cybersecurity pos...

Next Article
CyberArk Blueprint for the Federal Government
CyberArk Blueprint for the Federal Government

Follow the CyberArk Blueprint frame to design and effective Identity Security implementation roadmap that c...