Follow-up on Windows authentication

 

Let’s go back a minute to the Domain Controllers (DC), and the way users interact with them when they authenticate to a workstation or need to access a service on another computer.
At a successful logon of a user in a workstation, the DC generates an access token containing, amongst other things, the user’s Security Identifier (SID). A special ticket, called a ticket-granting ticket (TGT), carries this token. Whenever the user wants to access the resource hosted on another server, the TGT is sent again to the DC, which validates it, and reply back with another ticket, a resource access ticket (TGS). Finally, the user can contact the server, emphasis on can, and presents this TGS to gain access to its resources.
An attacker with enough permissions can abuse this convoluted exchange to gain persistence in your infrastructure.

 

Service Principal Name

 

Usually, for a service, such as a database, to run on a Windows server, an administrator needs to configure two prerequisites. First, a service account has to be created, which will be used to effectively run the database. Then, a unique identifier, called a Service Principal Name (SPN), must be added to this account. The users wishing to contact the database send these SPNs, along their ticket-granting tickets, to the DC. All of this is required so that the DC knows which service the user wants access to, but also, and this is the most crucial point, because the DC will encrypt the resource access ticket using the service account password hash. That way, only the service can decrypt the TGS and allows access or not to the user.

Now, the funny thing is, an attacker with enough rights can add a fake SPN to a targeted account, such as an administrator one. Then, to regain domain access privileges, the attacker needs only to contact the DC and request access to the fake SPN. All it takes next is to crack the resulting TGS, a technique called kerberoasting, which can be done offline, leaving no log on the contrary of a brute-force attack. To add an insult to the injury, you will remember that the attacker does not even need to send the TGS to the service, hence, producing even less traces that could be traced back to the origin.

There are effective ways to be protected against kerberoasting, which by the way is also used for silver tickets creation, and SPN abuse. Monitor all accounts with SPN, and delete them when not needed. There is no reason whatsoever to ever have a SPN associated with a user account, even less to an administrator one, so keep a look out for them.
In regards of kerberoasting, ensure that service accounts passwords are complex, enough so they will not be cracked. Consider the machine accounts, which are more than 100 characters long, opposed to human generated passwords. The simplest way is to achieve the same level of security is to use managed service accounts to manage them.

(Un)constrained delegation

 

Windows authentication, by its own flexibility and complexity, offers a large attack surface, for those who know where to look. Let’s say, for example, that your company provides a network share for the employees to store and retrieved their files. More often than not, these files are available via the company’s intranet website. In a typical windows environment, the file share would be hosted on a dedicated server, and the website on another. Users can access their files either directly, or via their favorite website.
In the former case, users are directly authorized by the network share. No issue there, if the folders access rights are properly configured, users from the accounts department cannot access the shared folder of the IT department. In the latter case, however, how are the users authorized?
Well, Microsoft came with a solution that lets the webserver impersonate the users and authenticates on its behalf on the network share. This mechanism is called credentials delegation, and comes in two flavors:

• Constrained Delegation: the webserver is trusted for delegation only for the specified services
• Unconstrained Delegation: the webserver is trusted for delegation for any services

If we follow the authentication flow explained earlier, users will ask for a resource access ticket (TGS) to the DC with their ticket-granting tickets (TGT), which will be presented to the website. But, surprise, there is an twist in the plot when Unconstrained Delegation is enabled. The DC will also put a copy of the user’s TGT inside the TGS. That’s how the webserver can impersonate the users, simply because it has these tickets in memory.
Now, all an attacker needs to do to achieve persistence in the active directory is to keep access to a single compromise server with Unconstrained Delegation enabled, and wait for a domain admin to use the service to steal its TGT. Et voilà!, instant access to the entire domain. Which include access to KRBTGTaccount password hash, just for the sake of creating a new Golden ticket.

So, how to mitigate such attacks? Put simply, Unconstrained Delegation should never be used, only Constrained Delegation. Furthermore, all elevated accounts should get the special property ‘Account is sensitive and cannot be delegated’. Lastly, the Protected Users Security Groups can be leveraged to apply additional protections to members’ accounts.

Security Support Provider

The ability to steal domain admin credentials inconspicuously at any given time is a key factor to retain persistence. Key loggers can come to mind, but they might be too easily detected. Credential dumpers are another option, but Microsoft has recently buffed up the security of the service in charge of keeping them safe, the Local Security Authority Subsystem Service (LSASS).
For one, there is LSA protection, which should be enabled on every servers. And with Windows 10 and Windows Server 2016, Microsoft introduced another feature to mitigate attacks to obtain credentials and hashes: Credential Guard. With Credential Guard, secrets are stored in a hardened and isolated section of the computer, inaccessible from the normal operating system. That was for the PR talk, now, under the wood (pun intended), it simply means that LSASS is split into two processes, one running as usual in the Windows Operating System, the other one in a virtual environment. From the attacker point of view, the visible LSA process does not hold anymore any unencrypted credentials.
This is all well and good, but attacker are endlessly creative, and found a way to bypass some of these protections, through a feature called Security Support Providers (SSPs).
SSPs are pluggable extensions to the Windows authentication system. Microsoft provides several of thesepackages out of the box, but what if an attacker was to actually register a malicious SSP, gaining the ability to steal any authenticated credentials? Well, if you think about something like that, it probably means that attackers are already doing it, and indeed, some of the most popular tools, intended for research only, implement this functionality.
So while implementing the latest security measures provided by Microsoft is definitely a must, it is not failproof. Careful monitoring of the services running on a Windows hosts must be done, as well as the security packages loaded.
For further references, Microsoft has several articles on the limits of credentials guards.

 

Directory Services Restore Mode

 

When domain administrators deploy a new Active Directory Domain Service (AD DS), they need to turn servers into Domain Controllers to manage the service. This is called promoting the server into a DC, and requires amongst other things the creation of a very specific local account, the Directory Service Restore Mode account (DSRM).
As the name implies, this account is used to perform a restore of a DC from a backup, a process that must only happen with the Active Directory service offline. However, as the name does not imply, this account has local administrator privileges. This account’s password is rarely ever changed, let alone monitored.
Obviously, from an attacker point of view, gaining access to this password is almost the equivalent of having the keys of the kingdom, as to elevate from a local administrator on a DC to a full domain admin, there are only a few steps. But, even better, since Windows Server 2008, this password can be synchronized from another account password. That’s right, an attacker with enough privileges can pick an account under his control, and push this account password on the DSRM account.
For further persistence, this task can be scripted, or pushed via Group Policy, two mechanisms that can also be abused and will be more detailed later.