"Advanced Cyber Knowledge" (ACK) - A deep dive into various cybersecurity concepts and attacks.
WDigest Decoded – Understanding LSASS and Why WDigest Was/Is so vulnerable
Let me start off first by saying that I love stealing credentials on a red team/ pen testing engagement, especially from a Windows host. I don’t know what it is about digital pickpocketing, but it’s such a satisfying feeling. Especially when you find a host that has WDigest already enabled, and you see those plain text passwords. Like, even getting on the host in the first place doesn’t compare to me, and it’s not like it’s an extremely difficult thing to accomplish, but that got my ADHD brain spinning. Why isn’t it a difficult thing to accomplish? At first, I asked myself, is it the fault of the Local Security Authority Subsystem Service(LSASS)? Or is it something different? So, like anyone with a brain like mine, I hyper-focused on the process, its operating cycle, and how tools like Mimikatz abuses it, and from that, I really got in deep with why Wdigest is the only section in Mimikatz that reads out the password in plain text.
So, first, let us start off with the basics and talk about LSASS as a whole.
For as much shit as we give the process, it’s actually an amazingly written toolset for Windows authentication handling. It’s efficient, modular, and absolutely core to the operation of Windows. At a 10,000ft down look LSASS is responsible for enforcing the security policy on the system. It verifies users logging in, creates access tokens, and even writes to the Windows security log, and it does this without sucking down your memory like a Chrome browser opened to a basic HTML text page. It’s able to do this for a few reasons. The first is, at its core, how it is written to dynamically handle credentials. LSASS stores credentials using a double-linked list, which is a data structure where each element contains a link to the next node in the sequence. if you aren’t a programmer, the non-technical description would be like playing a really good round of “telephone”. if you had to visually describe it with shitty text, it would look a bit like this:
Absolute chaos looking at the diagram, but looking at the data structure isn’t any easier either. Like if we pull from what is defined in Mimikatz for Wdigest we will see the following structure,
typedef struct _KIWI_WDIGEST_LIST_ENTRY {
struct _KIWI_WDIGEST_LIST_ENTRY *Flink;
struct _KIWI_WDIGEST_LIST_ENTRY *Blink;
DWORD UsageCount;
struct _KIWI_WDIGEST_LIST_ENTRY *This;
LUID LocallyUniqueIdentifier;
} KIWI_WDIGEST_LIST_ENTRY, *PKIWI_WDIGEST_LIST_ENTRY;Even more Chaos, but very efficient. This structure doesn’t even list the credentials, even though they will be stored in the same continuous segment of memory. This is for the process to know where the other credentials are. To break down this structure real quickly; “Flink” and “Blink” are pointers to the next and previous entries “UsageCount” is a count of how many references there are to this entry
“This” is a pointer to the current list entry
“LocallyUniqueIndetifier” is the LoginId
This is a really cool way to store data as it enables the application to dynamically store a new entry in the first available slot in memory, meaning that each node will always know where the next and previous node is, so you don’t need a giant continuous memory array like you would if you were to build, well, an array. I could probably go on a rabbit hole about this data structure, but let’s be real, that’s pretty boring. So instead, let’s talk about the second reason why LSASS is sweet AF, and that is Security Support Providers, aka SSPs. SSPs are what give LSASS its modularity. These little packages are individually responsible for enabling LSASS to be able to process many different authentication protocols. By design, these SSPs are compartmentalized and can be swapped in and out as needed by LSASS through their individualized DLLs. This modularity is beneficial in Window’s multi-protocol environment, as it allows LSASS flexibility to adapt to any supported authentication need by the user or application. Though this capability is also what makes LSASS so weak. Because SSPs are handling sensitive authentication data and transforming the data to meet the required authentication protocol needs, gaining access to these can provide us (emulated) criminals with valuable information. Think of SSPs as the workers of the process. Since the SSPs are managing and storing the data, the weakness afforded by that particular type of authentication is stored as well, and that brings us to the SSP of the hour, WDigest. So WDigest, is the easiest way of stealing credentials, hands down. This is because the Digest Authentication type was meant to be an HTTP authentication method. Its purpose is to allow Web Servers and clients to negotiate credentials above a less secure “basic authentication,” which was sending usernames and passwords in plain text over the network. On paper, it makes sense. The Digest authentication method is meant to provide security against eavesdropping as it hashes the user/pass combo before sending it across the net. It also has replay attack preventions implemented into the method by way of a nonce, aka a unique number that the server generates for each hash. This nonce can be time-limited or count-limited to ensure that the session is unique. Though these simplistic yet effective security methods are null and void because of how WDigest hashes the combo. This is because the Digest Authentication method requires the server to have access to the original password to create the hash. This is the root of the problem. Because Windows is about creating an environment that is intuitive and easy to use, the developers needed a way to create hashes for the Digest Authentication on the fly, and the easiest way to do that was to have the SSP store the credentials instead of asking the user to input their credentials every time as they created the SSP to be an SSO type manager for the authentication method. Now back in the day, this wasn’t so much of an issue as, let’s be real, cybercrime wasn’t in the same place as it is now, so the implementation was an effective way of managing the method, but since cybercrime is where it is today, Microsoft went ahead and made an adjustment to the everyday Windows v8.1 and above. Basically, they started to encrypt the passwords and disabled the SSP by default since, you know, not many people use WDigest for everyday work. Though in all its glory, Microsoft couldn’t be bothered to remove a glaring hole, you know, for the sake of backward compatibility. So, WDigest still lives.
In fact, if you are in a position to steal credentials, aka you have administration privileges to the host, you can turn back on WDigest authentication.
To do this, all you have to do is navigate to the following registry key
“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest”If the DWORD “UseLogonCredential” doesn’t already exist, then create it and set the value to 1.
That’s it, now you wait. In fact, when I was still conducting Red Teams, this was my go-to method for getting credentials. No need to crack hashes if you can get the plain text, and really at most, you just had to wait a day. If it went on any longer than a day, I would just reset their computer at night. EZ PZ passwords.
Anyways now I know too much about LSASS….
Comments