Active Directory: Simple measures for more security (Part 1)

To increase security within the Active Directory, small organizational measures in conjunction with free tools are usually sufficient. Many widespread attack vectors can at least be significantly curbed with a few small changes and fairly simple measures. The word "attacker" often appears in the following article, but "attacker" does not necessarily mean a person who has set themselves the task of penetrating a network. In the following article, "attacker" also stands for automated malware, which is sometimes designed to find as many victims as possible, but is not very targeted in its approach.

Introduction

Especially in small environments with only a few servers and clients, on-board resources and free tools can be used to ensure a certain level of security and at least make it more difficult for attackers to access the company's crown jewels.

The first part of the article series deals with a little theory, the second article then describes the implementation using an example. But first the theory.

Widespread gateways and attack vectors

The biggest gateway for viruses and Trojans of all kinds, but also for targeted attacks on companies, are emails. From fake job applications with malicious attachments to customized phishing emails targeting users' access data, such emails always manage to get past spam filters and virus scanners. Once the mail has arrived in the mailbox, users recognize phishing mails as phishing with a rate of 59 %. The probability of a user opening a malicious email is therefore quite high. Here you can find an article worth reading:

Emails are the most important gateway for cyber attacks

Another popular gateway is the browser; known security vulnerabilities are exploited by websites in order to obtain user access data or smuggle malware onto computers.

Once an attacker has managed to gain control of a single computer in the company, the rest is surprisingly easy. If you already have a foothold in the company, "lateral movement" is often a popular method for penetrating further into the network. With lateral movement, an attacker initially moves "horizontally" and as inconspicuously as possible in the network without causing any damage. The aim is to gain control of other computers, so an attacker would, for example, try to gain control of other clients in the network from an infected one.

Especially in companies where Active Directory is used, "Pass the Hash (PTH) or "Pass the Ticket (PTT)" attacks often occur after lateral movement. An attacker waits on infected clients until a privileged account (e.g. a user with administrator rights in the Active Directory) logs in. The attacker can now use the password hashes or the Kerberos ticket that the privileged user leaves behind on the infected computer to work his way deeper into the network. If the attacker manages to obtain a Kerberos ticket from a domain administrator, he can use it to log on to the company's servers and domain controllers. Almost all data would then be visible to the attacker and the only thing left to worry about is how to get the data out without being noticed. A very well-known example of an attack that was carried out according to this pattern, was the German Bundestag in 2016.

This type of attack does not require a great deal of specialist knowledge if the target is not necessarily the Bundestag. Various viruses and Trojans can carry out such attacks completely automatically. A company does not have to become "relevant for hackers" first, it may be enough to catch a virus on a computer.

Incidentally, the attack method and procedure described here is not new and has been working for years, so you should not rely solely on virus scanners and spam filters.

Admin Tiers: Why, why, why!

Similar to the segmentation of the network using VLANs, you can also imagine the segmentation of the Active Directory into admin tiers. Servers, services and clients are divided into 3 tiers. Tier 0 contains the most critical systems, in this case the domain controllers, for example. Tier 1 contains servers that provide services for the clients, such as file servers or web servers. Tier 2 contains all clients, i.e. PCs, notebooks and printers.

The classification of the systems into the admin tiers is not based on the criticality of the respective services of a server, but on the number of systems that the respective server or service controls. For example, a domain controller controls all other systems within the Active Directory, which is why the DCs are in Tier 0. A file server, for example, can be very important for the company, as users are not able to work without network drives, but the file server does not control any other servers, clients or services. A file server is therefore assigned to Tier 1. Clients then form Tier 2.

Here is a small graphic to illustrate this:

Source: Active Directory management level model

The aim of the Admin Tiers is to ensure that Tier 0 systems are allowed to control Tier 0, Tier 1 and Tier 2 systems (e.g. a DC with group policies controls Tier 1 and Tier 2 systems), but a Tier 1 or Tier 2 system is not allowed to control a Tier 0 system.

NoteExchange servers are to be classified as a Tier 0 system if the Exchange servers have not been installed in the "security model for shared authorizations". However, the Exchange installation without "Active Directory security model" is the default setting:

The graphic makes it a little clearer:

Source: Active Directory management level model

For example, a Tier 1 system is given control over Tier 0 systems if it executes services with Domain Admin authorization. This could, for example, be backup software that is executed as Domain Admin for the sake of simplicity. This would allow the backup software with Domain Admin rights to manage the domain controllers and thus the Active Directory (higher tier control). As shown in the image, however, the "Higher Tier Control" must be prevented.

If you wanted to make things easy, you would simply classify the backup software as a Tier 0 system. However, Tier 0 should be kept as small as possible, so the better way is to configure the backup software accordingly so that it no longer runs with domain admin rights.

In addition to the control level, the admin tiers should ensure that an account that manages Tier 0 systems cannot log on to Tier 1 and Tier 2 systems. A user account that is a member of the Domain Administrators group (Tier 0) is therefore not allowed to log on to a web server in Tier 1 or a client in Tier 2.

This graphic makes it a little clearer again:

Source: Active Directory management level model

Note: If there is only one server in very small environments (Domain Controller, Exchange, etc. on one server), then there is also only Tier 0 and Tier 2. Different admin accounts are then used for these two tiers.

Briefly summarized:

• Domain administrators log on to domain controllers (Tier 0), but not to file servers (Tier 1) or workstations (Tier 2)
• Server administrators log on to file servers (Tier 1), but not to clients (Tier 2). However, if the role requires it, the server administrator may log on to a Tier 0 system (for example, to an Exchange server to create or manage a mailbox)
• Client administrators log on to clients (Tier 2), but may also log on to a server that manages the clients (Tier 1)
• Tier 1 and Tier 2 systems must not be given control over Tier 0 systems (backup software with a service with domain administrator rights)
• Tier 2 systems must not have control over the higher tiers (backup software or own user account with domain admin rights)

And what are the Admin Tiers supposed to achieve now?

The strict separation of control and access options is intended to prevent an infected client from gaining control over the critical systems of the higher tiers, for example. The backup software can again serve as an example: If the backup software comes with an agent that runs on all servers and clients with domain admin rights, an attacker could obtain the password for this account by infecting just a single client. Once the password is known, the attacker would have control over all systems within the Active Directory. If the limits of the admin tiers are observed and the backup software on the clients only runs with tier 2 admin rights, an attacker can also "only" get hold of the tier 2 admin password. The attacker would therefore have control over the clients, but not over the Tier 1 and Tier 2 systems (keyword: Same Tier Control and Lateral Movement). If the attacker now gets hold of an account with Tier 2 admin rights, he can move within Tier 2, but will find it difficult to access Tier 1 and Tier 0 accounts, as these are not allowed to log on to Tier 2 systems (lower tier logon).

Local Admin account: Administrator

Often the same password is always used for the local administrator account on the clients. The same usually applies to the servers, where the same password is often used for the local administrator password. Of course, it is very bad if the password for the local administrator is identical on clients and servers. Of course, everyone knows that identical passwords always represent a security risk, but nobody wants to manually assign a secure and individual password for every computer and every server.

However, the "Administrator" account is a popular target for attackers, as this account exists in the standard configuration on every Windows client and Windows server. If the password is always the same, it is all the better for the attacker.

To increase security here too, the password for "Administrator" must therefore be different on each computer (server and client) and should also be changed regularly.

However, it was reported in the media that Microsoft now only recommends changing passwords if it has become known that the password has been leaked:

• Windows 10 1903: Microsoft no longer recommends expiring passwords

However, this refers to the users' passwords, i.e. a user should no longer be asked to change their password every XX days. This recommendation does not apply to administrative accounts, which is also explained in this article:

• Security baseline (DRAFT) for Windows 10 v1903 and Windows Server v1903

So the problem remains: Individual passwords for local administrative accounts.

This is where LAPS comes into play. With LAPS (Local Admin Password Solution), each client and server generates a secure password for local admin accounts itself and saves the respective password in the Active Directory. LAPS is controlled via an agent on the clients (server and client) and group policies. Using the LAPS UI (GUI) or PowerShell, an appropriately authorized user can read and use the local admin password from the Active Directory. Group policies can be used to control when an Active Directory member changes the password and which requirements apply to the local password.

The following picture of how LAPS works only looks complicated at first glance:

Source: Local Administrator Password Solution

The LAPS Agent ensures that a local administrator password is changed at certain intervals and saves the corresponding password in the Active Directory. If the password is required, it can be read from the AD and used. Using LAPS, it is therefore possible to use individual passwords for local accounts without having to worry about the passwords yourself.

Domain Admin account: Administrator (or "Domain Admin")

The "Administrator" domain account is a particularly worthwhile target for viruses and attackers, as this account has administrative rights on every Windows client and server within the Active Directory. Within the Active Directory, the administrator account has the most authorizations and also the right to obtain all necessary authorizations itself. As long as the administrator account is activated and, in the worst case, is still actively used for administration, an attacker often has an easy game. The attacker already knows the user name and can easily find out the SID of the account, so all that is missing is the password or a hash / ticket...

To make it at least more difficult for attackers, the administrator account should be deactivated. Only the accounts of the respective admin tiers are then used for administration. It is therefore not necessary to create a copy of the domain admin account.

The question here is rather, how often do you need an account that has "Domain Administrator" privileges? As a rule, such far-reaching authorizations are only very rarely required; the tasks for day-to-day business can be delegated to accounts with fewer privileges.

Admin Hosts

An admin host is a dedicated workstation that is used to administer the server. The Admin Host is therefore not used for "normal work" and should not have access to the Internet. All relevant tools for the administration and management of Active Directory and other services can then be installed on the Admin Host (RSAT Tools, Exchange Management Tools, SQL Management Studio, etc.).

To avoid having to constantly switch back and forth between two computers for administration purposes, an RDP connection can be established from your own computer to the Admin Host. The following measures help to protect the admin host itself:

• The Windows Firewall is configured so that it only allows RDP connections from certain PCs
• Inactive sessions are logged off after a certain time (e.g. 30 minutes)
• Kerberos tickets are deleted when the user logs out

Small rule of thumb: The Admin Host cannot be reached from the Internet, neither via RDP nor via Teamviewer or similar tools. If you need to perform administrative tasks remotely, you can establish a VPN connection and then connect to the admin host via RDP.

The Windows firewall of the server can also be configured so that only RDP connections from the admin host are permitted.

Note: In principle, an admin host can also be operated as a virtual machine. It would be conceivable, for example, to use Hyper-V or VMware Workstation on your own workstation. However, it should be noted here: In this case, the VM is used for normal day-to-day business and the physical installation is then considered the admin host. As a rule, it is a major hurdle to break out of a VM and thus gain access to the admin host. Conversely, the path is easier for the attacker; once access to the hypervisor has been gained, it is easy to gain access to the VM.

Windows Admin Center

The Windows Admin Center is a free software for browser-based management and administration of Windows servers. Windows servers can thus be conveniently administered from your own workstation without running the risk of leaving Kerberos tickets for privileged accounts on your own workstation. This means that a dedicated admin host is not necessarily required to perform standard tasks. Windows Admin Center can also establish RDP connections directly from the browser.

Of course, the Windows Admin Center should not be accessible directly from the Internet. If you want to perform administrative tasks from your home office or remotely, you should establish a secure VPN connection and then connect to the Windows Admin Center.

Here, too, there is a simple rule of thumb: Administrative interfaces (e.g. Windows Admin Center, HPE iLO, Dell iDRAC, vSphere Webclient, etc.) must not be directly accessible from the Internet.

Updates, updates, updates

A lack of updates sometimes makes it particularly easy for attackers. Automated attacks in particular target outdated systems with known security vulnerabilities. So what can we say about this topic? Updates must be installed as soon as possible, not only for the Windows operating system, but also for all other programs used in the company. Unfortunately, the topic of updates usually causes the most effort, as it is often not even known which software is used in which version and where.

However, there is another simple rule of thumb: software with a high degree of distribution has the highest priority when it comes to updates. The attack surface can be significantly reduced if at least the operating systems, Office programs and browsers are up to date. Automated attacks in particular are based on security vulnerabilities in standard software that is widely used. So if this standard software (e.g. Windows, Chrome, Firefox, Office, Adobe Reader, Flash (!) etc.) is at the latest patch level, many automated attacks will fail.

PowerShell can be used, for example, to determine which software is used particularly frequently in the company; in addition to the Windows operating system, this could be the Chrome or Firefox browsers, for example. The most frequently used software should therefore also be provided with updates quickly. WSUS can help with the installation of Windows updates. With a little effort and planning, other software such as Chrome or Firefox can also be automatically provided with updates.

Summary

The measures described here do not replace other solutions in terms of security. For example, if every user in the company has administrator rights, there is generally no need to worry about admin tiers, as there are other basic tasks to fulfill first. The measures described serve to make it more difficult for attackers, but of course this does not make an attack impossible.

The next article deals with the implementation of the options described. Further articles will also discuss other additional measures.