Least Privilege Examples, as told by the Three Ghosts of “A Christmas Carol”

With the holiday season upon us, it’s a good time to settle down with a beloved story. I re-watched the Charles Dickens classic, A Christmas Carol, the other day (well, actually it was Scrooged with Bill Murray, of course) and found myself thinking about the parallels with cybersecurity. Really, I did.

In the story, Ebenezer Scrooge is first visited by the Ghost of Christmas Past. They watch scenes from the past, rich with examples that made Scrooge into the miserable person he became. Next, the Ghost of Christmas Present and Scrooge look in on the Cratchit family, where he sees their humility and love for each other. It’s a stark example of what he doesn’t have in his own life. Last, the Ghost of Christmas Future shows Scrooge what will befall him if he doesn’t change his ways.

What examples would cause us to change our cyber behavior today?

I started thinking: What if we were visited by ghosts like these? What examples would they share that would cause us to change our cyber behavior today?

I think they’d show us scenarios of companies that failed to take proper precautions and suffered the consequences.

In that spirit, let’s “visit” organizations that suffered an avoidable loss by not adopting the principle of least privilege security. These examples of least privilege security breaches illustrate how embracing this critical cybersecurity principle today can change your future.

Least Privilege Examples from the Ghosts of Cyber Past

1. The Ghosted Device

IT organizations often use ghosted images to provision user endpoints with a common configuration. While this approach improves efficiency, when done improperly it can create a gaping security hole: users who should have standard credentials instead set up with privileged credentials. As local administrators, business users can make changes to settings, run any programs, and install any software they want on their endpoints – including applications that could leak data or have other security risks. Any malicious cyber criminal who gains access to their endpoint will have that ability too.

Ghosted images with default passwords cause other problems too. Default passwords are rarely changed, resulting in the same password being used across thousands of systems for years on end. If each local domain account, guest account, or other built-in accounts and local domain groups have the same default passwords, and those passwords aren’t updated, someone who gains access to the default information would then have access to any number of devices.

What started out as a way to make IT more efficient has the opposite impact: opening doors to malicious cyber criminals.

Lessons from this least privilege example

The best security practice is to ensure local admin group membership is used appropriately. By minimizing a user’s access to only the bare necessities, you can start with a zero-trust posture and implement least privilege access from the start. Taking a lifecycle approach to managing privileges also includes regular audits and culling unneeded or elevated administrator rights.

Even administrators should have different accounts for different use cases. Instead of “one account to rule them all,” they should have specific, privileged accounts used for access or running certain applications such as updates, access databases or backups, etc., and a standard account to use for general purposes.

Applying the principle of least privilege to endpoints prevents attackers from moving around the network, reusing an account.

2. Over-Privileged Third-Party Contractors

a.k.a. How an air conditioner repairman unwittingly compromised personal data of 100 million Target shoppers

Seemingly mundane building infrastructure, like a refrigeration unit, can become a weak link in an organization’s network security once it becomes remotely accessible to third-party vendors. Malicious cyber criminals can steal network credentials from these systems and use them to access other parts of an organization’s network. It’s a foothold that can spawn a much larger attack.

That’s what happened to Target and resulted in the theft of more than 100 million people’s personal information.

Target, like many retailers, outsources the maintenance of its HVAC systems to third-party contractors. The units are tied into the retailer’s network so the third party can monitor and maintain the equipment remotely. The contractors are often given administrator-level privileges, granting them far more access to the corporate network than they actually need.

In Target’s case, one of the HVAC vendors was targeted by cyber criminals, who were able to install malware on a technician’s machine. The malware enabled them to harvest user credentials, which they used to access other parts of the Target corporate network, eventually landing in the POS system containing valuable data on Target’s customers. More than 100 million people were ultimately impacted by this security breach.

Lessons from this least privilege example

Vendors should never have admin rights on your network. This is especially true if you don’t manage the devices they use to access your network.

As a starting point, any user accessing your network using vendor credentials should be subjected to an always verify and always monitor policy. Always verifying means that each time a vendor attempts to access a resource on your network, they are forced to authenticate using multi-factor authentication. That also goes for subsequent access to other resources. An always monitor policy ensures that all actions taken by a vendor are recorded by default, and available for later audit or review. Third-party vendor credentials should always be limited and any elevation to privileged access should be on-demand in real-time.

It takes a systematic approach to prevent this example of a least privilege security breach. A standard mitigation strategy includes conducting discovery to find out which endpoints and local users have admin rights, what applications are in use, and if they require admin rights to run. Once that is known, it becomes a matter of layering security: integrate compliance and regulations, control access and action, incorporate application control, and manage and protect the privileges granted to users.

3. Helpdesk Staff with Superuser Super Powers

IT help desk teams must have access to a broad swath of devices to troubleshoot user issues. Granting them unfettered access, or giving them uncontrolled access over privileged accounts, could result in a least privilege security breach.

To assist users, help desk staff may need direct access to an individual’s machine. Since they often need access to applications like Task Manager or Process manager to conduct troubleshooting activities, they may log into a machine using domain-level accounts.

There are two worst-case scenarios that stem from this lack of least privilege policy.

• A help desk staff member accesses information that they shouldn’t. This could result in non-compliant access to sensitive information or, worse, data exfiltration.
• Alternatively, if the domain credentials fall into the wrong hands, they could be used in an external attack to infiltrate critical IT systems.

Lessons from this least privilege example

The help desk does need special privileges to be able to do their jobs, but there also needs to be least privilege controls in place to prevent security breaches. Rather than allowing blanket elevated privileges, have them login using a standard account, and provide a mechanism to elevate their privileges for specific use cases or endpoint applications. Even if credentials are stolen, with least privilege security in place, an attacker would be severely restricted.

Another way to allow a user to have access to programs and processes that would normally require admin privileges is to set up a specific network share that is provisioned to be read-only. Then, any scripts needed to do upgrades, configuration changes, patches, etc., could be sanctioned and placed on the network share. From there, appropriately credentialed people could access and run the scripts, but they wouldn’t be able to modify them. Known users would be allowed to execute known applications and run the right tools.

A variant of this approach is to designate an approved software catalog, which is derived from a reference system with an approved list. Each item on the list is tested, validated, and granted permission to be run. In other words, authorized users will be permitted to execute known good applications, and they’ll be unable to run unknown or known bad ones.

4. Malware Leads to Widespread Power Outages in Ukraine

In this next example, a least privilege security breach started with malware that gave the wrong people access to a network. It continued as the threat agents carefully navigated and probed different systems, looking for vulnerabilities, moving laterally, and escalating privileges. That’s what led to sabotage of the Ukrainian power grid. And it could have been prevented.

The Ukraine attack was initiated with a precise spear-phishing campaign aimed at technical administrators for three of the many power distribution companies responsible for managing the power grid. They were sent emails with a Microsoft Word document attached. Opening the attachment prompted the administrators to enable macros for the document. Any administrators who clicked “yes” unleashed BlackEnergy3, a program that stole user credentials, and opened a backdoor for criminal hackers to access their machine, and by extension, the network.

Once the criminal cyber criminals had access they were able to navigate within the corporate network. But, since the corporate network was segregated from the network running the power grid, they needed to find another way in. Eventually, by methodically mapping the network, they were able to get access to the Windows Domain Controllers and the network and user credentials housed within. With these credentials, they could access the SCADA network which controlled the power grid. It was just a matter of time before they turned the power off which is what exactly happened, leaving thousands of homes without electricity.

Lessons from this least privilege example

This type of exploit has been around since the 1990s. It’s usually easily defended against through antivirus software, which scans attachments for malicious payloads and restricts which applications can be run on an endpoint.

When implementing the principle of least privilege, application control policies help you maintain productivity by allowing trusted applications and commands and denying those you don’t trust. You can specify which software is allowed to execute and which should never be run, and you can sandbox any software that is ambiguous or hasn’t yet been tested. Validation occurs in the background, invisible to users.

Other least privilege examples include limiting the types of actions a user can take, such as preventing them from running a program downloaded from the internet, using a USB stick, accessing file shares, scanning all email attachments, and preventing unrecognized executables from being run.

What Will the Ghost of Cyber Present Show You?

Now that you’ve visited these least privilege scenarios from the past, you can take a hard look at your own present.

The best way to get the unvarnished truth of your least privilege status is to run a Discovery scan of your IT environment. Delinea's free Least Privilege Discovery Tool indicates which accounts may be overprivileged and vulnerable to insider threats and malware attacks.

After running the scan, you’ll get a customized report that highlights issues with user workstations, IT infrastructure, and services, operating systems, and applications. The prioritized results will help you:

• Identify accounts with local administrative privileges to determine which should revert to standard accounts with limited system controls.
• Find elevated privileges on IT resources, as well as services accounts and credentials that are improperly shared or past their expiration date.
• Inventory applications on your network and see which are flagged as malicious or insecure.

Least Privilege Strategies to Change the Future

The Ghost of Cyber Past showed you examples of lax least privilege practices that led to security breaches. Running a discovery scan on your own environment will likely reveal issues in your least privilege security posture. Visiting the past and the present wasn’t enough for Scrooge to change; for that, he needed to see the future.

How about you?

While we can’t see all the details of your future, we know that cyber attacks have become a permanent and persistent threat. It’s fair to say that an attack on your organization isn’t a matter of “if,” but “when.” The question is: How well will your security policies mitigate these common examples of least privilege security breaches?

The good news is you still have time to change

• Remove local admin rights from endpoints and servers.
• Create application control policies that block unsafe and malicious software.
• Elevate privileged access only when needed.
• Adopt the principle of least privilege across your entire organization, including end-users, administrators, and third parties.

We’re here to help you in any way we can

For more examples of least privilege security and guidance on how to plan your least privilege strategy, check out the eBook, Least Privilege Cybersecurity for Dummies.