The series will address the following attacks:
- Plain-text password grabbing (wdigest LSASS/SSP)
- Pass-the-hash (LM, NTLM, NTLMv2, Kerberos AES)
- Overpass-the-hash (also referred to as pass-the-ticket)
- Golden Ticket
I will give a rundown of each attack as I understand them, and then provide current supposed methodology for mitigating against them. I am assuming that the initial attack stages were successful, and a payload with remote callback/shell has been acquired. For example, meterpreter (msfconsole). In other words, these are post-exploitation attacks aimed at escalating privileges ultimately to domain domain.
Before I go any further I need to point out that the primary method of securing your infrastructure from any of these methods is managing privileged accounts. None of these attacks can be done without local administrator rights escalation first (harder to do than it sounds). That means that the attacker must gain local administrator rights on a workstation in order to make use of these strategies. If you or your staff are operating with local administrator rights then there is almost nothing you can do…
(TL/DR)
By its nature, reading LSA to gain information on accounts is a post-exploitation event. This means that the attacker already has root to the machine they are looking into. This means any operating systems parameters used to secure the machine are almost entirely trivial. I would argue that the exception is when someone is operating 2012 R2 functional domain, has all local administrator accounts disabled, and network admins use domain accounts (delegated for only local system administration and have no domain admin rights) which are placed in the Protected Users group to remotely administer systems. No matter what, an attacker can update registry to try to force LSA to store passwords – it will not store for these protected users! So you only run into a problem when a domain users who is not in the protected users group logs into a system where they have domain administrator (could be a service too).
Plain-Text Password Grabbing
This is the worst. Believe it or not there are probably a swath of people vulnerable to this method (more later). This is the low hanging fruit for anyone on the network (think: inside threats). How does it work? Well, Microsoft needs to offer single sign-on. That means any system you log into must “cache” your credentials somehow for future use and then forward those credentials (securely) to an application or remote application. You are supposed to rest easy knowing that TLS is used to encrypt your password on the wire when your workstation “automagically” authenticates you to that web application. The problem is that the password is stored without encryption locally (therefore encrypting over the network is useless) in various states (a couple hashed version and plain-text) in memory by the Local Security Authority Server Service (LSASS). When your credentials are needed to sign you on remotely without your input an SSP (Security Support Provider) will grab the password from LSASS, throw it into a TLS connection and sign you on remotely. I only mention TLS because a lot of network managers think that this is enough security. It is not. TLS only secures you against MITM (man in the middle) attacks (passive network sniffing for plain-text passwords). Before the SSP authenticates you over a secure network connection (TLS), it might need to have access to your plain-text password so that it can authenticate on your behalf without your input. Why plain-text? Because not all we applications or 3rd party systems support Kerberos, etc. There are a couple problematic SSPs which support such use of plain-text passwords for various applications. First, Digest SSP (often referred to as “wdigest” which is the name of the DLL). Digest SSP (or just “Digest Authentication”) was developed to aid in passing credentials to web applications (e.g. a company intranet site). Second, CredSSP also relies on the plain-text instance of your password in LSASS. Rather than being used to authenticate a user against web applications, CredSSP’s job is to authenticate you against terminal services / RDP. Even worse, if you authenticate to a remote computer it’s very likely that you are leaving a plain-text copy of your password there as well! Gee, thanks CredSSP! CredSSP is also used for remote Powershell. There may be other SSPs that attempt to store and access plain-text copies of our passwords too. They will place the password in LSASS, so our ultimate goal for this method will be to restrict LSASS’s ability to store passwords in plain-text (or to restrict SSP’s from doing this). More on that in a minute…
How It’s Exploited
Tools
There are a couple of well known tools for reading contents of LSASS in memory.
- Windows Credential Editor (often referred to as just “wce”).
- Mimikatz
Reading memory is obviously not proprietary. Therefore, it should be assumed there are a number of other projects or malware packages that will do this. Personally, I enjoy using Mimikatz. This tool is a favorite of pentesters and excellent for blue teams to validate their mitigation techniques. Benjamin Delpy (creator of Mimikatz) is a fantastic researcher.
Prerequisites
- Tool of your choice (Mimikatz)
- Access to target system (either remote or physical access)
- Local Administrator privilege is a requirement
Ease of Execution
This information is extremely easy to get. Every beginning “hax0r” learns these techniques out the gate.
Execution
Once you execute mimikatz.exe on the target machine with local administrator privileges you simply need to issue two commands:
mimikatz #privilege::debug
mimikatz #sekurlsa::wdigest
The output will look something like this (I have sanitized it)
mimikatz # sekurlsa::wdigest
Authentication Id :
Session :
User Name : username
Domain : domain
Logon Server : domain controller
Logon Time : user's logon time
SID : user's SID
wdigest :
* Username : username
* Domain : domain
* Password : password (the fun part)
This blog is not intended to teach people how to execute attacks. These facts are well documented. It should be noted that this can be done remotely, quite easily with tools like psexec and metasploit / meterpreter.
Mitigation Steps
Disclaimer: I am not making any claims or guarantees with this info, nor its completeness. Both the threat and the mitigation are dynamic events that change day to day. As of the writing of this post, these are considered published mitigation techniques. Whether they are effective or not is debatable
Because tools like Mimikatz are post-exploitation and require local administrator rights before they are useful, it’s safe to assume that most of these security features can be trivial to undue. For example, if someone has managed to acquire local administrator rights on a system, it’s trivial to make registry changes. As we will see below, Microsoft has included registry settings to tweak whether SPP is allowed to store credentials or not in plain-text. Same for RDP security. It’s so easy to silently change these things, even if they are being pushed from Group Policy.
Patching
There are patches for this problem. I will try to summarize here, but suffice it to say it’s a little confusing. Microsoft has a good rundown under Security Advisory 2871997. In Windows 8.1 and Server 2012 R2 Microsoft added support for (null) storage of plain-text passwords (SSPs are no longer allowed to store plain-text passwords in LSASS). You must explicitly modify these systems to permit it in Windows 8.1 and Server 2012 R2. They also created a new switch in the RDP client called /restrictedAdmin, and if not called out then the default was to use RDP with restricted admin. Excellent! But most organizations are still using Windows 7. Therefore, Microsoft backported all of this to previous versions of Windows, and released as a patch under KB2871997 (applause). Subsequent patches were released to provide support for modifying the restrictedAdmin feature via registry (CredSSP). It gets better…the backported operating systems (e.g. Windows 7) left wdigest (Digest Authentication SSP) alone. While all other SSPs would no longer be allowed to store plain-text passwords in the LSA, Digest still can. An additional registry entry must be made on these legacy Operating Systems to prevent Digest SSP from continuing to operate in its less secure mode! The reason for this is that Microsoft did not want to break customer’s applications. Therefore, they offered a neutered solution by forcing those who want to be more strict to “opt in”. It is for this reason that I believe there are thousands of exposed credentials still being exposed on patched workstations. That is nuts! I will cover how to fix this under the registry sub-heading.
Registry
Make sure your applicable systems have the following registry values. This I know for certain from our own testing, that a patched Windows 7 system will still publish the LSA plain-text passwords. It will continue to do this until you update registry and reboot.
- HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredentials=0
- This registry entry should be added to all Operating Systems prior to Windows 8.1 and Windows Server 2012 R2 after they have installed patch 2871997
- HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin=0
- This registry setting should be enabled where applicable – you should review the Security Advisory carefully.
Windows 10 Advancements
This post has been a work in progress for the last 2 years or so. As I am finally publishing on July 19th 2016, there are important updates available related to mitigating these attacks. Specifically, Windows 10 Isolated User Mode. Rather than cover it in details here I will provide links to a few educational resources:
Use Protected Users Group
Microsoft created a new “Protected Users” group, which LSASS is not allowed to store passwords for, let alone hashes! We will discuss this group more in future posts, but suffice it to say in a Windows Server 2012 R2 functional level domain it is critical that you add your domain users that are granted local administrator rights on systems to the Protected Users group! There’s a few more domain settings that I will cover when we review the hash exploits, as it relates to storing only secure hashes so that passwords cannot be “cracked”. More on that later.
Additional Best Practices
Absolutely no one in your organization should be running as a local administrator. One pain with accessing LSA is that it requires an administrator privilege set. That is a significant road block. Enough so, that most pentesters will look at alternative approaches on the network for gaining credentials other than reading LSA. Additionally, domain administrators should never be allowed to log into any system other than a domain controller. One of the easiest ways to protect passwords is to only use them where necessary. God forbid we have an unpatched system containing credentials in plain-text for a domain administrator! In my environment, domain admins cannot even use RDP to connect to domain controllers. They must connect directly to the console (virtualization makes this less annoying).
Leave the built-in local Administrator account disabled (if it’s not, then disable it). Microsoft added a lot of security to the Local Administrators group, preventing various pivot techniques for its’ members. Except, they allowed one exception: the built-in local Administrator account. So just disable it. Go ahead. What are you afraid of? Seriously. Do it.
Use Microsoft LAPS (or something) for Local Account Password Management. I suppose if you must keep a local Administrator account handy, then at the very least use unique passwords for each local account. If the passwords for every built-in Administrator account in your Windows network are the same, then pivoting from machine to machine is moot for an attacker. It’s a matter of time before they find a hash of more value somewhere and escalate to a domain or worse, domain administrator. An alternative tool: SHIPS by TrustedSec.
Resources
Here are a list of links / resources that I found helpful.
Other Solutions
There are vendors out there that can protect memory space of processes such as lsass.exe. For example, CarbonBlack Enterprise Protect (formerly called Bit9). Cb Protect has the ability to watch and restrict what areas of memory certain processes are able to access. This solutions is agent based (requires an agent on the endpoints). Policies are used to determine how the agent behaves, and in this case policies can contain types of rules such as a “Memory Rule”. At its most basic function the memory rule can block read and write in memory space reserved for lsass.exe by any other process. So quite literally, no other processes can access the memory space of lsass.exe except lsass.exe. This is a great mitigation. CarbonBlack is not the only vendor that can do this. I believe that most application white listing vendors will offer this type of feature. Again, this rule is a defense against post-exploitation abuses where someone is already on your systems (abusing existing tools or having ran malware). Application white listing is one step up in that it is designed to prevent the running of any untrusted binary/PE files. In the event that this does not work as it is designed, then a memory rule should add additional “post-exploitation” defense.
Summary (TL/DR)
By its nature, reading LSA to gain information on accounts is a post-exploitation event. This means that the attacker already has root to the machine they are looking into. This means any operating systems parameters used to secure the machine are almost entirely trivial. I would argue that the exception is when someone is operating 2012 R2 functional domain, has all local administrator accounts disabled, and network admins use domain accounts which are placed in the Protected Users group to remotely administer systems. No matter what, an attacker can update registry to try to force LSA to store passwords – it will not store for these protected users! So you only run into a problem when a domain users who is not in the protected users group logs into a system where they have domain administrator (could be a service too).
Feel free to comment.
thedefensedude.com 