Privileged Password Management Explained Part 2: Managing Passwords & Attack Techniques

Last week, we introduced the basics of what privileged credentials are and why they need to be managed, and also covered some universal challenges and best practices applicable to all types of passwords. In today’s blog, the second in our series, let’s examine some challenges more specific to an enterprise’s privileged credentials.

Read the entire series now in Privileged Password Management Explained, the definitive primer on privileged password security.

Challenges to Managing Privileged Passwords

Lack of visibility and awareness of all of the privileged accounts and credentials across an enterprise poses a monolithic challenge—especially for those companies that rely on manual processes and tools. Privileged accounts, many long forgotten, are sprawled across most organizations. Different teams may be separately managing—if managing at all—their own set of credentials, making it difficult to track all the passwords, let alone who has access to them and who uses them. An admin may have access to 100+ systems, possibly disposing them to take shortcuts in maintaining the credentials. Beyond this, as elaborated in the sections below, some types of credentials are virtually impossible to find, let alone bring under management, without third-party tools.

Lack of privileged credential oversight and auditability: Even if IT successfully identifies all the privileged credentials strewn across the enterprise, this does not by default translate into knowing what specific activities are performed during a privileged session (i.e. the period of time during which elevated privileges are granted to an account, service, or process). Privileged access to a superuser account should not amount to ceding carte blanche to the user. Moreover, PCI, HIPAA, and other regulations require organizations to not just secure and protect data, but be capable of proving the effectiveness of those measures. So, for both compliance and security reasons, IT needs visibility into the activities performed during the privileged session.

Ideally, IT should also have the ability to seize control over a session should inappropriate use of the credentials occur. But, with potentially hundreds or concurrent privileged sessions running across an enterprise, how does IT expeditiously detect and halt malicious activity? While some applications and services (such as Active Directory), can log user actions, and while Windows servers using logon events within Event Log data can reveal some behavioral anomalies, expect full coverage over privileged account usage to require a third-party solution.

Sharing of privileged accounts for convenience: IT teams commonly share root, Windows Administrator, and many other privileged passwords so workloads and duties can be seamlessly shared as needed. However, with multiple people sharing an account password, it may be impossible to trace actions performed with an account to a single individual, complicating auditing and accountability.

Hard-coded / embedded credentials: Privileged credentials are needed to facilitate authentication for app-to-app (A2A) and application-to-database (A2D) communications and access. Applications, systems, and IoT devices, are commonly shipped, and often deployed, with embedded, default credentials that are easily guessable and pose formidable risk until they are brought under management. These privileged credentials are frequently stored in plain text – perhaps within a script, code, or a file. Unfortunately, there is no manual way to detect or centrally manage passwords stored within applications or scripts. Securing embedded passwords requires separating the password from the code, so that when it’s not in use, it’s securely stored in a centralized password safe, as opposed to being constantly exposed as when in plain text.

SSH keys: IT teams commonly rely on SSH keys to automate secure access to servers, bypassing the need to manually enter log-in credentials. SSH key sprawl presents a substantive risk for thousands of organizations, which may have upwards of a million SSH keys—many long dormant and forgotten, but still viable backdoors for hackers to infiltrate critical servers. SSH keys are standard, and more prevalent, in Unix and Linux environments, but are also used across Windows. Admins leverage SSH keys to manage operating systems, networks, file transfers, data tunneling, and more. As with other privileged credentials, SSH keys are not necessarily tied to a single user—multiple people may share the private key and pass phrase to a server, which holds the public key. As with other types of privileged credentials, when organizations rely on manual processes, there is a pronounced tendency to reuse a passphrase across many SSH keys or to reuse the same public SSH key. This means that one compromised key can then be harnessed to infiltrate multiple servers.

Privileged credentials and the Cloud: The challenges of visibility and auditability are generally exacerbated in cloud and virtualized environments. Cloud and virtualization administrator consoles (as with AWS, Office 365, etc.) provide vast superuser capabilities, enabling users to rapidly provision, configure, and delete servers at massive scale. Within these consoles users can spin-up and manage thousands of virtual machines (each with its own set of privileges and privileged accounts) with just a few clicks. One predicament then arises around how to onboard and manage all of these newly created privileged accounts and credentials. On top of this, cloud platforms frequently lack native capability to audit user activity. And, even for those organizations that have implemented some degree of automation for their password management (either through in-house, or third-party solutions), if not architected with the cloud in mind, there’s no guarantee a password management solution will be able to adequately manage cloud credentials.

Third-party vendor accounts / remote access solutions: Finally, another quandary for organizations is how to extend privileged access and credential management best practices to third-party users, such as consultants or other vendors that may perform a variety of activities. How do you ensure that the authorization provided via remote access or to a third-party is appropriately used? How do you ensure that the third-party organization is not sharing credentials, or otherwise exercising poor password hygiene, such as by failing to terminate authorization credentials when an employee departs from the company?

Some Common Password Attack Techniques

Password attacks come from all angles. Some programs, such as John the Ripper and L0phtCrack, can even crack complex passwords, while Pass the Hash toolkits can be lethal without even cracking the password. Here are some common credential exploit tactics:

• Brute force attacks involve repeatedly testing a password, potentially generating millions of guesses per second, with combinations of characters (numbers, letters, and symbols) until one matches. The more mathematically complex a password, the more difficult to crack.
• Dictionary attacks: As opposed to a brute force type assault that computes random combos of characters, dictionary type attacks make password guesses based on words in a dictionary of any language.
• Pass-the-Hash (PtH) attacks can occur on Linux, Unix, and other platforms, but are most prevalent on Windows systems. In Windows, PtH exploits Single Sign On (SS0) through NTLM, Kerberos, and other authentication protocols. When a password is created in Windows, it is hashed and stored in the Security Accounts Manager (SAM), Local Security Authority Subsystem (LSASS) process memory, The Credential Manager (CredMan) store, a ntds.dit database in Active Directory, or elsewhere. So, when a user logs onto a Windows workstation or server, they essentially leave behind their password credentials. In PtH attacks, an attacker doesn’t need to decrypt the hash to obtain a plain text password, once captured, the hash can be passed through for access to lateral systems. A hacker could elevate privileges simply by stealing RDP credentials from a privileged user during an RDP session.
• Pass-the-Ticket (PtT) and Golden Ticket Attacks are similar to PtH, but involve copying Kerberos tickets and passing them on for lateral access across systems. A Golden Ticket attack is a variation of Pass-the-Ticket, involving theft of the krbtgt account on a domain controller, which encrypts ticket granting tickets (TGT). With this prized foothold, a hacker could freely create his/her own access tickets for any level of access and duration of access. Rotation of privileged account passwords after every use and least privilege enforcement (such as separating different types of privileged and non-privileged accounts, and even better, removing admin rights from endpoints) are important security controls to thwart PtH, PtT, and Golden Ticket attacks.
• Social engineering password attacks, such as phishing and spear phishing, involve tricking people into revealing information that can be used to gain access. Recent, highly visible, victims of a spear phishing attack included the Democratic National Committee (DNC), John Podesta, and others by the hacking group, Fancy Bear. In Podesta’s case, he apparently received a spoof Gmail email alerting him that an imposter had tried to use his password, but that Google had detected the illicit activity and stopped it. Apparently, Podesta then clicked on an illegitimate link to change his password, and, thusly, his credentials were stolen, then later used to pilfer and dump embarrassing emails on WikiLeaks.

Next week, in the third and final blog of this series we will cover privileged password management best practices and benefits, along with resources to help you improve your security and oversight of privileged credentials.

Also, for further lessons into how to protect your privileged credentials from both inside and external attackers, check out this on-demand webinar with Security Expert, Nick Cavalancia: A Hacker’s Perspective – Where Your Password Strategy is Lacking.