What Is a Domain Controller?

A domain controller is a type of computer server that responds to security authentication requests and verifies users on the domain of a computer network. The controller is a gatekeeper for allowing host access to domain resources. It also enforces security policies, stores a user’s account information, and authenticates users for a domain.

This blog looks at the approach attackers use, after gaining an initial foothold on a domain controller, to discover and understand an environment prior to moving laterally. Many of the techniques effectively “live off the land” of an endpoint or server to eventually get to domain controllers and launch an attack. Our next post will examine some ways attackers move laterally, and lastly, we’ll explore mitigations for preventing lateral movement.

Attackers find a way in.

Once they do get in, it is a matter of moving laterally, often to reach the domain controller in order to orchestrate an attack. Once an attacker has access to it, they are effectively an IT admin, so “living off the land” could not be easier. Let’s examine an attack, assuming breach—that an attacker will eventually find a way in.

But first, let’s look at domain controllers. You likely know this already, but a Microsoft Domain Controller server, Active Directory, is responsible for authenticating access (verifying users logging on) to a Windows domain and associated network resources. It holds a directory of users, groups and computers and is a repository of network services such as file shares, network shares and printers. A server provisioned with the Active Directory Domain Services roles becomes a domain controller. It is also installed with a DNS server to manage name resolution and other internal network services. Although quite heavily GUI driven, a domain controller and active directory server are very complex, especially in a typical corporate network where there is likely to be several for replication and fault tolerance.

As a result of the heavily intertwined roles on a Windows domain, the domain controller hosts many different services depending on the number of roles it is provisioned to perform. Roles such as DNS for name internal resolution, Kerberos ticketing for authentication, Server Message Block, Certificate services and a whole lot more. This broadens the attack surface and indeed there are many attacks against components such as:

• Single Sign-On Credential Use
• Kerberos ticketing,
• Service Principal Names (SPN),
• Group Policy Objects (GPO),
• Active Directory Trusts & Delegation
• RPC and SMB.

Most of these attacks are heavily facilitated by network traversal. All these services come with associated ports and protocols.

The table below shows the ports and protocols likely to be used by a typical domain controller that must be left open. This amounts to an expansive attack surface that bad actors can make use of. The challenge is that if we decided to close ports, to reduce attack surfaces, Active Directory ceases to function properly.

Path to the domain controller

The premise here is aligned with the assume breach philosophy which implies that a threat actor may already have unauthorized access to your systems or network, albeit possibly with lower-level privileges. For example, this could be the compromise of a user account via phishing that may, in turn, lead to business email compromise (BEC). This will also imply that the threat actor is more than likely trying to work their way to a higher privileged account and subsequently crown jewel system such as the domain controller.

Let’s look at a hypothetical attack flow following this pattern:

The initial attack involves a phishing email to an employee. This phishing attack contains a link to a fake Office 365 OneDrive login which the employee falls for. In conjunction with javascript execution and in some cases vulnerability, such a link automatically runs a memory-only malware leveraging Windows Powershell. This then leads to a reverse shell command and control (C&C) backdoor from the compromised user’s Windows laptop back to the attacker. This is the starting point for this article’s ‘assume breach’ premise.

The attack up to this stage will be mostly automated so the attacker will likely get a C&C notification about a new shell and therefore a new compromised machine. They are also going to be mainly oblivious of the full details of the compromised system such as user accounts, privileges and network resource access. This is where the ATT&CK Discovery Phase is important to an attacker.

ATT&CK: Discovery

What is the first thing you must do to pivot from a single system, be it employee endpoint or workload, to a domain controller?

As ATT&CK would say in the Discovery phase, “try to figure out the environment.”  

Adversaries begin by understanding who the user of the system is, the running processes, file/directory/group membership and session information.

Tools like NMAP for port scanning are an option to get a lay of the land to see what services are listening on remote machines they can exploit.  Additionally, Bloodhound can be used to map the Active Directory environment to understand the fastest way to the domain controller.

These tools have been used in attacks, however, they have an inherent challenge. They draw too much attention to themselves as third-party tools that generate traffic. They are chatty and somewhat overt, meaning they could be detected by security systems.

Attackers are best served by simply "living-off-the-land" when they have access to a domain-joined endpoint or workload. This way they use tools that are native to the endpoint and don't generate any noise on the network.

Attackers can begin with basic CLI commands many of us are familiar with as an easy, discreet way to understand where they are and what they can do next.  

On a domain-joined client machine, commands like whoami will allow for the discovery of the system owner or user, and show an output similar to what is shown below.

This lets the attacker build an account profile of the compromised system to see what that account has access to.  A quick look at the Active Directory groups that the machine is a part of lets the attacker discern that the user is for example, on the Finance team. They know that they’ll likely have access to finance file shares to exploit or may choose to immediately examine files on the machine if finance data is what they are after.

The threat actor can also use a simple yet effective command like net users and associated switches to discover the name of the domain controller their compromised machine is joined to and the list of user accounts that exist on the domain controller.

From here, there is a clear set of important details that can aid their path to the domain controller.

Other simple commands many are familiar with are ipconfig /all and netstat -rn to orient the attacker to the default gateway and network, subnet, DNS and DHCP information.  They can also see what is reachable given the routing table. This gives the attacker enough information to build out a basic map of network level connections. They can decipher whether or not their compromised machine is sitting on the same subnet as the Domain Controller or DNS Server. For this reason, it is imperative to have a micro-segmentation approach for which the security is workload dependent rather than network dependent even in a flat network architecture. Security that follows the workload like a Domain Controller irrespective of subnet or location.

They may also be able to decipher additional subnets and routes and their corresponding Gateways and corroborate that routing information with reverse DNS details of, for example, network share server names.

Most organizations use network shares for employees within the same team to share and sometimes archive information. Threat actors can leverage Windows network share detail from built-in utilities such as net use to locate File Servers or even domain controllers. They can also use this information combined with any compromised or escalated accounts to access hidden Windows network shares like AMDIN$ or C$. These can be used to facilitate the spreading malware to other machines over the local SMB network or through a valid remote access VPN connection connected to an SMB network.

With this information, we can now see what shares and servers we have access to in Windows, below. Once the attacker has a bit more information about the compromised system under their control, they can formulate the next plan of action.

In this example, the user is a local administrator for their laptop, they have a VPN adapter in their list of NICs and a corresponding VPN application but do not have any Domain Admin access. Since a core aim is to get access to the Domain controller, the attacker has a few options like trying to escalate privileges which can be used for lateral movement. If there are no other accounts present on the system for which privileges can be escalated, then they will most likely have to try to get such an account. They could leverage the authenticity of the compromised account and machine to send even more targeted phishing attacks inside the organization’s email domain. They could also cause a man-made glitch on their targeted system to force an IT support case which will most likely mean a remote help session with an IT admin who will more than likely “Run as administrator” on the infected machine. Threat actors tend to be determined and are patient and will typically do whatever it takes to get what they are after.

It is important to note that up to this point, we have not even used more powerful native capabilities like PowerShell or WMI. This is to deliberately point out the amount of information that can still be obtained on legacy operating systems as on modern ones. For example, the attacker may yet still test the possibility of native remote access using a system tool like PowerShell to see what machines they access remotely to aid lateral movement and pivoting.

Powershell Remoting capabilities offers up yet another avenue of discovery and lateral movement capabilities with commands like Enter-PSSession and various other cmdlets that can run the ComputerName parameter. The former utilizing WinRM (HTTP 5985 and HTTPS 5986) and the later the more ubiquitous RPC.

We understand the importance of domain controllers, we know an intrusion has occurred, and now we have a better understanding as to how attackers can use simple CLI commands and the all-important living off the land techniques (that won’t generate noise your endpoint or network security tools will see) to get a lay of the land and discover where they are in an environment.

Our next post will examine the lateral movement that attackers exhibit after discovery, to get to the domain controller.