The fourth part of our (E)SAE Deep Dive series is about regularly changing non-personalized accounts. As a reminder: In our July blog post we already presented the first of our top ten measures. Today the second measure follows.

According to the Verizon Data Breach Investigations Report 2020, about 80% of hacker attacks use login information that has been stolen or captured by brute force attacks. It is therefore surprising that the BSI, NIST and Microsoft2019 have changed their password policies to no longer recommend changing passwords regularly. But what is behind this?

The reason for this is the realization that IT system users write down passwords or use very similar passwords when they are forced to change passwords frequently out of convenience. Because of this behavior, it is therefore better to use a longer, more secure password, such as a passphrase, once only, which is then only changed on an ad hoc basis (e.g. after a security incident). However, this is not a phenomenon that applies to non-personalized accounts. For this reason, we believe that passwords of non-personalized accounts should continue to be changed regularly. This article explains the types of non-personalized accounts and their risks.

What are non-personalized accounts?

These are accounts that are not assigned to a natural person. For example, service accounts, the local administrator account in Windows, the root account in unix systems such as Linux and MacOS, or predefined accounts in appliances and databases.

In the context of Windows and Active Directory, there are three prominent accounts (types) that we discuss in our infographics:

1. 1. service accounts are accounts in whose security context a Windows service is running In addition to a predefined account, a service can run under a local user account or an Active Directory user account, both of which have passwords. If you take the definition a bit further, accounts used to run Scheduled Tasks or in scripts are also included here.
   2. If a domain controller fails, it can only be restored For this purpose, the domain controller is restarted in Active Directory Service Restore Mode (DSRM). In this mode the Active Directory Services are not active and the accounts in the Security Accounts Manager (SAM) database are used.
   3. the krbtgt account is a predefined local account under which the Key Distribution Center (KDC) runs and which encrypts Kerberos tickets

Attack scenarios and their effects

In the following, we would like to present some well-known scenarios that show what possibilities an attacker has to gain possession of “Credential Material” (identifiers, hashes or Kerberos tickets) and what he can do with it.

Service accounts

To fulfill the purpose of the Windows Service, Scheduled Task or Script, a service account often requires more than just user rights. Depending on the purpose and (mis)configuration, the rights can range from write permissions on local directories to Domain Admin rights. Therefore, the damage caused by the use of a service account cannot be assessed in a general way. However, experience from customer projects shows that service accounts often have high rights (often more than necessary) and are a worthwhile target for attackers.

But how does an attacker get the password?

Non-technical possibilities

Unfortunately, all too often passwords are not handled properly. They are sent in unencrypted e-mails, stored in Excel or SharePoint lists. We have also seen Domain Admin passwords on whiteboards😳 .

IT employees quit or are fired, and the separation is not always a good thing. If the passwords are not changed after every employee change, the former employee can use these passwords in case of an attack.

Rather known from the field of appliances but depending on the process also a problem for service accounts: standard passwords. If, for example, a default password is used when creating the accounts and this is not changed, an attacker with knowledge of the procedure (processes are after all documented 😊 ) can take advantage of this.

Technical attack scenarios

A simple attack scenario is the repeated and random testing of passwords via a remote logon. Since the Active Directory locks the account after too many unsuccessful logon attempts within a certain period of time, a real attack takes quite a long time even with a relatively short password.

A Kerberoasting attack is much faster. However, the exact technical background would lead too far here. Important in our context is that once a service has registered a Service Principal Name for a user account (not for the computer account), any user in AD can request a Service Ticket (TGS), which is encrypted with the password hash of the service account. The attacker can download the ticket from the main memory (e.g. conveniently with Rubeus) and calculate it on his system with a password cracker like Hashcat. Don’t get us wrong, by calm we mean hours with today’s computing power and not days or weeks, as was the case a few years ago (with a complex 8-character password).

Another possibility is to use the mimikatz module sekurlsa and the command logonpasswords to read hashes and, if necessary, plain text passwords. To do this, the attacker must be able to gain local administrator rights on a system on which the service account is logged on. As of Windows 8.1/Windows Server 2012 R2, the passwords are no longer stored in plain text in the main memory by default. However, the NTLM hash is enough for the attacker to execute local or remote commands with the rights of the service account. Depending on the authentication protocol used, this is either a Pass the Hash (PtH)– or Pass the Ticket (PtT) attack. If a ticket is used by a service account, it is also called a Silver Ticket .

In principle, the hash can also be extracted offline from the NTDS.dit database or using DCSync. More about this in the following sections.

DSRM

To get the password of the DSRM account, there is social engineering as well as extraction with mimikatz, analogous to the way via the service accounts. To do this, however, the attacker must already have domain administrator rights.

Now the question arises, of course, why should an attacker use the DSRM account if he is already a domain administrator? If the attacker has the password of the DSRM account, he can boot into DSRM mode, use the PowerShell module DSInternals to mount the Active Directory database NTDS.dit offline and create accounts there without logging these activities. The goal of using the DSRM account is therefore not to increase privileges, but to find a way to persist unobtrusively in the Active Directory and use it undetected for a longer period of time.

KRBTGT

The krbt account is, as described above, the service account of the Key Distribution Center (KDC) service and is used to encrypt Kerberos tickets.

We are aware of the following ways to get the hash of the krbtgt account:

• Again, an attacker can extract the password from DC using mimikatz.
• An alternative way to get the password hash of the krbtgt account (or any other account) without having to log on locally to a domain controller is to use the mimikatz module lsadump with the command DCSync. This command can be used to request the password hash of the krbtgt account via a replication with a domain controller over the network.
• The last possibility known to us is to read the Active Directory database NTDS.Dit offline with the PowerShell module DSInternals. For access – either to read it directly or to copy it – the database must not be in write access of another process. Therefore, the NTDS service and its dependent services must be stopped for access with DSInternals. In addition, the so-called boot key is required, which is stored in the registry hive SYSTEM. This is different on each domain controller and is used to decrypt the Password Encryption Key that is used to encrypt the data in the database.

If the attacker has the hash in his possession, he can then use it to create a Golden Ticket. A golden ticket is used like a silver ticket in a pass the ticket attack. In contrast to a Silver Ticket, where “only” the rights of the service account are obtained, the Golden Ticket allows the attacker to impersonate any user (this user does not even have to exist in the Active Directory) and to add any group memberships to his ticket. As if that wasn’t bad enough, an attacker can also write arbitrary SIDs into the SID history and thus compromise the whole forest from any subdomain! As an additional icing on the cake, the attacker can also freely configure how long the ticket is valid 😊 .

How can you protect yourself?

In general, it is important to use a long complex password to make password cracking and hashing more difficult, and to change the password regularly to increase the duration of the attack for the attacker. Windows supports passwords up to 127 Unicode characters long for both on-premises accounts and Active Directory accounts.

In the following, we will discuss what to consider when changing passwords in the scenarios shown in the above graphic, and how to avoid manual password changes for service accounts.

Service accounts

Changing the passwords of service accounts is not trivial in a typical business environment. Depending on the size of the company and the number of applications in use, keeping track of service accounts can become a challenge. Changing a service account password often requires updating the Windows service as well as the application configuration in one or more places. The storage location and the way of updating differs from application to application. It may be necessary to restart the service, which leads to an interruption in the operation of the application.

Therefore, the simplest solution is not to change the password manually. There are several solution options for this:

• The use of a predefined account like LocalSystem, LocalService or NetworkService. These accounts all have no password and are therefore easy to manage, but they do not provide granular permissions management and do not allow you to isolate permissions of a service.
• Virtual Accounts are local accounts that can access network resources and whose password is regularly changed by Windows. The name of a virtual account is NT Service\<Service Name>, for example, the virtual account name for the default instance of a SQL Server Database Engine is NT SERVICE\MSSQLSERVER.
• A Managed Service Account (MSA) is a domain account whose password is managed by a domain controller. An MSA can register a Service Principal Name (SPN) and ends with a $ character (DOMAIN\ACCOUNTNAME$).
• Unlike an MSA, a Group Managed Service Account is not limited to one server, but can be used on multiple servers and can therefore be used for fault-tolerant technologies such as Windows Clustering or Network Load Balancing (NLB).

However, virtual accounts or managed service accounts must also be supported by the application, which unfortunately is not the case in many cases.

This means that the passwords of traditional service accounts – either local Windows accounts or Active Directory user accounts – must still often be changed manually. This is no trivial task due to the large number of accounts. Therefore, there is a variety of different tools that support the process to varying degrees. In addition to password managers such as KeePass, which only support the generation and secure storage of passwords, there are also full privilege access management solutions that offer far more functions than “just” changing and managing passwords of service accounts. Market leaders are CyberArk and BeyondTrust. An inexpensive alternative to the market leaders is passwordstate.

DSRM-Account

The password can be changed using the ntdsutil.exe tool. As described, it is a local account and must therefore be changed on each domain controller.

Since Windows Server 2008, the password of the DSRM account can be matched with that of a domain user account. This is also done with the ntdsutil.exe tool. Caution: This is not a proper synchronization. If the domain user’s password is changed, the DSRM account password is not automatically changed. Our recommendation is to set up a separate and long password for each domain controller.

krbtgt-account

The password of the krbt account can usually be changed with Active Directory Users and Computers. The password used is irrelevant; a long, complex password is automatically generated. Because the password history of the krbt account stores the two most recent passwords, the password must be changed twice to ensure that an attacker who has captured the current hash cannot use it.

However, caution is required here. If the password is changed twice in quick succession, all tickets lose their validity. All accounts must re-authenticate. Application services may have to be restarted for this. To avoid the interruption this causes, the Kerberos Ticket Lifetime (default 10 hours) should be at least the duration of the Kerberos Ticket Lifetime between two password changes.

It should also be ensured that the new password can be replicated correctly to all domain controllers. Sounds trivial at first, but in large global Active Directory implementations, it can happen that a domain controller is unavailable for some time.

To make the password change easier, Microsoft has provided the script New-KrbtgtKeys.ps1. It has several modes to safely test the replication before changing the password and monitoring the actual replication.

Summary

A picture is worth a thousand words. This article has once again proven the proverb to be true. What started as a short supplementary post to the infographics has developed into an article of almost 2,500 words. We hope that the work has been worth it and that you understand why it is important to take care of the security of non-personalized accounts through our explanations, background information and linked articles, which are dedicated to each topic in detail. As always, we look forward to your comments and are happy to engage in dialogue with you 😊 .