Credential Theft and How to Secure Credentials
Published: January 21, 2015
Author: Dana Epp, Microsoft MVP - Enterprise Security
I’ll never forget the day. It was Valentine’s Day in 2006. Bill Gates was on stage at the annual RSA Conference conducting a keynote speech related to next generation trust and announced that Microsoft was laying the foundation for change, so that in the next three or four years, corporate systems would not need to rely on passwords. He explained the vision to simplify certificate management and drive identity management through an interesting piece of technology called InfoCards. It was a bold announcement and a pretty cool demo; could Microsoft really take on and solve the challenge of having to eliminate the need to use weak password authentication? Could password fatigue really be behind us by 2010?
Well, it’s 2015 and we all know the answer to that. While several key pieces of the identity metasystem for InfoCards remain in the guts of the Windows operating system and many bits laid the foundation of what became Microsoft’s federation strategy, we still use passwords. Everywhere. And what’s worse, we now have more of them. On our desktops. Our phones. Our tablets. Heck… I had to log on to my TV this morning to apply an update. With the Internet of Things (IoT), password authentication isn’t going away anytime soon.
Adversaries are happy about that. Password authentication, especially in Windows environments, opens up huge attack vectors that make it almost trivial to laterally move throughout the network. You may have heard about these techniques under the veil of “pass-the-hash” or “pass-the-ticket” attacks. In fact, last year at TechEd, Mark Russinovich and Nathan Ide did a great presentation to demonstrate how attackers spread across a Windows network using this technique. I encourage you to check it out.
So just what can we do about it? Well, there are several key pieces of technology built into Windows that you can use to help secure your credentials and make it much more difficult to have them stolen and reused. From what I am seeing in the field, very few people seem to be using these security features. So let’s explore them and see if I can convince you why they are valuable assets in your IT security toolkit.
For this article, I am looking at this issue from the viewpoint of an IT administrator. Consider the type of access you typically have with those type of credentials. If an adversary is able to impersonate you in this context, chances are the game is over. So our goal should be to restrict how and where we use these credentials. Let’s start by discussing how to reduce the credential footprint.
The crux of Administrator credentials
It shocks me how many people use the primary domain Administrator account to log on to pretty much everything in a Windows domain. This is a bad practice, and should be frowned upon. That account has far too many privileges, and poor use of the account exposes you to great risk. It becomes trivial for an attacker to elevate and take control of the domain when there is credential residue from any account that exists in the Domain Admins group… but when you use the primary administrator “500” account you take it to the next level. Why? Because after you have control of that account you can lock out pretty much everyone. It is difficult for a member of the Domain Admins group to seize control of the primary domain Administrator account; the same is not true the other way around. Let’s come back to that in a moment.
Let’s start by talking about the local Administrator account. This is where most attackers begin their adventure to steal credentials. I won’t get into the fact that most deployments these days include ways that a user can elevate to local Administrator privileges with a single click of a button. I hate this. I wish more companies would actually deploy Windows to make users and applications run as standard users and force them to use UAC in prompt mode, instead of consent. The key difference being you then need to enter in the local Administrator password to elevate. Then again, it’s quite easy to get that password… or at the very least reset it.
If you are a fan of my Web TV show “Crack the Cred,” you may have seen a demonstration I did in episode 104 where you can use the Microsoft Desktop Optimization Pack (MDOP) to generate a Diagnostics and Recovery Toolkit (DaRT) USB stick that includes a tool called Locksmith. This tool allows you to reset the local Administrator account in just a few clicks, which takes control over the computer in a supported way by using tools Microsoft provides to its partners. The fact is though that these days, most Windows desktops are built in a way that it may be even easier to gain access.
In many cases, deployment images end up using the same local Administrator account. In fact, on many occasions I have seen IT teams forget to clear out critical files like the sysprep.inf, sysprep.xml, and unattend.xml files, which hold either plain text or base64 encoded plain text administrative credentials. That’s right. There is a good chance you can retrieve the local admin creds in clear text in a file left from the IT team when they made the deployment image for your desktop. And if you use Group Policy Preferences, it is trivial to extract the encrypted password because the AES key used for it is actually published on MSDN! Have I scared you yet? Surprisingly, not everyone knows about this credential residue during automated deployments. But your adversaries do. In fact, there are hacking tools that scan and extract these in just a few seconds, making it easy for them to gain local Administrator privileges on all of your computers across the network that use that same credentials. This allows lateral movement in an effort to find more privileges on other more-trusted systems. This leads me to our first mitigation.
Prevent network logon for local accounts
Local accounts are stored in the Security Accounts Manager (SAM) database, which is part of the registry. If the SAM has the same username and password (like when using automated deployment) an attacker can use NTLM and move laterally from one device to another without any trouble. If these computers are on a domain, you really shouldn’t be granting this. So one mitigation technique is to simply not allow that.
In the Security Policy Editor (secpol.msc) under “Local Policies->User Rights Assignment” there is a policy called “Deny access to the computer from the network”. Introduced in Windows 8.1 and Windows Server 2012 R2 is a new well known group called “NT AUTHORITY\Local account” or just LOCAL_ACCOUNT for short. If you add that to the policy, then local accounts on the computer cannot be used across the network. So even if someone knew the password, it could not be used to remotely connect to another computer. This immediately eliminates the primary method of moving laterally across the network in search of higher credentials.
Prevent access to in-memory credentials
When sessions are established in Windows, a reference-counted object is created to maintain the session. The problem is that stale sessions still have a handle to that credential in memory for the lifetime of the connection and could keep it indefinitely… at least until the computer is restarted. Think about it… how many times have you closed an RDP session to a server without actually logging off? When you do that, your credential stays in memory. And even if you do log off, stale sessions may become orphaned and the credentials could be left in memory regardless. If you allow lateral movements from other servers as shown in the last section, it means it would be possible for someone with Administrative privileges to steal your credentials. Tools like Mimikatz make this extremely easy to do.
There are several ways to reduce this risk. First off, by default, operating systems newer than Windows 8 have had the credential footprint significantly reduced, wiping the plain text value out of memory. So you immediately benefit if you have upgraded. However, there is more you can do to harden the operating system to reduce the risk against tools like Mimikatz. TechNet has a great article on how to make the Local Security Authority (LSA) a protected process, by using a security hardening technique that has existed since back in the Windows Vista days. By setting the RunAsPPL registry key for the LSA, you set it up to prevent code injection that could compromise the credentials, which is essentially what Mimikatz does. One suggestion I have beyond this TechNet article is to leverage UEFI secure variables on startup, which prevents an attacker from being able to remove this protection and restart the computer. An attacker would have to gain physical access to the system and have the appropriate access to adjust the UEFI settings before they could remove the process armoring.
NOTE: One word of caution though if you harden LSA. When you make something a protected process, the process must be properly code signed. This means that if you use legitimate code that ties into an LSA like a smartcard driver or credential provider, they too must be signed. Otherwise, they will not be authorized to work with the LSA. So make sure you test this scenario against all of your authentication use cases.
Prevent credentials from remaining in-memory when connecting remotely
When you log on interactively to a computer using the Remote Desktop Protocol (RDP) you end up leaving your credentials in memory on the target system. With Windows 8.1 (and now recently backported to Windows 7) Microsoft added a new capability with a goal to reduce this risk called the Restricted Admin mode which you can enable in mstsc.exe using the /restrictedadmin switch. When you use this switch, instead of sending a user credential to the target it uses your Kerberos TGT to get a ticket to connect as the computer account. I’ve actually heard some people call this “Kerberozed RDP”. If you look closely what it’s really doing is using a Kerberos ticket through the network logon process instead of using a password on interactive logon. So it’s more like accessing a file share (but over RDP), than it is an interactive logon you see where you get a password prompt. In fact, when you use this switch you don’t get prompted for a password at all.
There is an interesting backstory to this approach. It was originally introduced to help battle pass-the-hash attacks by preventing the storage of credentials in memory. However, using it with Kerberos tickets makes it ironically vulnerable to the very same attack vector they were trying to plug up. Now you can use pass-the-hash with RDP. Some security experts question if this approach has any real value. I’d argue that this is a security tradeoff that is inherent to the authentication model in Windows. Regardless, a recent Windows update pushed a fix that disables the RDP Restricted Admin feature by default. If you want to use this approach, you need to go back in and re-enable it. You can find more information about this in the Microsoft Knowledge Base article KB2973351.
So why even talk about it if it’s disabled? Most of Microsoft’s guidance on protecting credentials continue to recommend this approach (including recent presentations and videos), even though the security community and Microsoft security itself have decided it’s not something that should be on by default. In actual fact, the Windows 7 backport only had a subset of the fix applied to allow for the invulnerable client mode without exposing the pass-the-hash server mode bits, making it safer. So if you are using Windows 7 and not Windows 8.1 it’s a reasonable option and actually positions you to be better protected than Windows 8.1.
Leverage protected users and control privileged users
A new Active Directory Security Group called Protected Users was introduced in Windows Server 2012 R2. Members of this group are afforded additional protections against the theft of their credentials during the logon process. People assigned to this group cannot use NTLM, digest auth, or CredSSP, which are the typical methods where credentials remain in memory and can be stolen. It also strengthens how Kerberos functions in both the encryption protocols used and the TTL for Ticket Granting Tickets (TGT). Instead of the default of 10 hours it’s reduced to 4 hours, which can be further reduced in time if you configure this with Authentication Policies and Silos. The result is the prevention of credential residue for hashing while reducing the window of exposure of a Kerberos ticket, all while strengthening it at the same time.
Now the Authentication Silos I just mentioned are rather interesting. They allow you to create bastions to restrict how and where credentials can be used. If you have a Windows Server 2012 R2 domain, you can apply Authentication Policies and Silos to help isolate users and/or resources, which allows for custom ticket lifetimes and restricts which users and service accounts can be used. A great place to use this is to isolate access to your domain controllers (DCs) where you rarely need people to have direct access to the system. An example might be to create a “DC Lockdown” Authentication Policy with a ticket lifetime of 1 hour which is set with a condition to only allow users to access it from “Silo” computers. Then you can create a “DC Lockdown” Authentication Silo and assign the policy you just created and set the members to be your tech admin (for example, Alice) and her PC (for example, Alice-PC). See where we are going with this? You can prevent account logon to the DC by anyone but Alice from her PC. So even if someone somehow stole Alice’s credentials, they couldn’t use them to log on to the DC interactively. This is extremely useful against attacks in which credentials are exfiltrated through tools like the Windows Credential Editor (WCE) where they can dump your Kerberos tickets and use them later for pass-the-ticket attacks. If you want to learn more about Authentication Policies and Silos there is a great article on TechNet you should check out.
Summary
I don’t know if you noticed, but I spent a lot of time in this article discussing mitigation strategies to avoid having credentials stored in the first place, and on hardening the environment so that if a credential is stolen you can reduce the impact on the resulting attack surface. Back in 2006 Bill Gates felt that Microsoft could lay the foundation to eliminate passwords once and for all. That couldn’t materialize as these credentials are just far too prevalent in our systems. Instead, Microsoft started to find ways to reduce the credential footprint to begin with, and then further reduce the credential residue that’s left over so attackers have a harder time leveraging it.
So where do we go from here? Start by running your logon session and applications as a standard user. Leverage delegated Administrator accounts with the least privilege needed to conduct the work you are tasked with. Don’t allow local accounts to connect over the network. When you have to use stronger credentials with higher permissions to do work across the network, consider where you do that, and ensure you harden the processes like LSA on your servers so you don’t leave too much credential information behind and don’t allow untrusted code to look at what’s left. Log off your sessions and don’t simply disconnect. Deploy Authentication Silos and harden the inner rings so that only the accounts required to access those services are authorized to do so, from computers authorized to do so. And above all, start treating your credentials like you do your underwear. Change them frequently. Never share them. Never leave them lying around. And they should be sexy. Oh wait… you are in IT, so maybe not. Let’s go for they should be mysterious and hard to figure out. And the longer the better. Especially on those cold nights when you are called in to deal with unauthorized access because someone else didn’t follow this advice.
.png "Dana Epp")
Dana Epp is the Principal Architect - Security, Identity and Access Management at Kaseya, where he focuses on the architecture and security of the next generation identity and access management platform for cloud-based IT management. He has spent the last 25 years focusing on software security and has been awarded the recognition and designation by Microsoft as an Enterprise Security MVP for the past ten years.