Take Me to Your Domain Controller: How Attackers Move Laterally Through Your Environment

Dan Gould also contributed to this post.

In the first part of this blog series, we saw different ways a threat actor can carry out the Discovery phase of the ATT&CK framework to gain a lay of the land after an initial infection. This gives them important network and domain information, even with standard domain privileges. We also noted some of the components used by a domain controller that may be attacked directly or leveraged as part of an attack.

Here, we will elaborate on this to show examples of attacks and tools that can be used against these components to execute the next phase of an attack: lateral movement.

Armed with this useful information, like those shown in the previous post in the discovery phase, the threat actor can now confidently attempt lateral movement on the path to the domain controller. However, they will need the necessary credentials, intermediate target systems and components information, combined with the corresponding attacking tools, to reach their ultimate target.

ATT&CK: Lateral Movement

Lateral movement, especially in a Windows domain, may occur at two levels. First the application level, where the attacker may use credential based techniques like pass-the-hash or pass-the-ticket which in turn leverages the network level where they actually move from machine to machine on the way to the ultimate target which in this case is the Domain Controller.

This brings us to credential-based techniques.

Credential-based techniques for lateral movement

Candidly, once domain admin credentials are uncovered, the domain controller is typically a command prompt away.

Attackers seek to dump credentials cached in common locations, like Local Security Authority Subsystem Service (LSASS), used to authenticate users, logins, and permissions on Windows. Why are credentials (hashed passwords/tickets) kept in memory? For single sign-on, it’s so users don’t have to reauthenticate all the time.

If attackers are in luck, they compromise a system that has past admin logins remaining in memory. Those login credentials can be coaxed out with Mimikatz or similar LSASS memory probing tools. As you know by now, Mimikatz and similar tools enable threat actors to find and extract authentication credentials like NTLM hashes and Kerberos ticket information from a running computer’s kernel memory used by LSASS.

The example below shows credential dumping using Mimikatz.

In most cases, the initially compromised account only needs to be a local administrator account on the Windows machine to be able to successfully run tools like Mimikatz. This means that it will have the necessary privileges, like the Windows debug privilege, to read kernel or privileged memory for certain crucial Windows processes like LSASS. As mentioned earlier, Windows domains rely heavily on single sign-on capability to offer an almost seamless experience for users and machines requesting resources across the domain. To easily facilitate this, Windows has been using the ability to store hashed credentials in memory and for the older versions, plain text passwords in memory. This is one of the main ways tools like Mimikatz are able to retrieve NTLM hashes and, in some cases, plain text passwords for techniques such as pass-the-hash and pass-the-ticket attacks.

Here is what dumping Kerberos tickets from memory looks like:

Another tool that can be used for Kerberos ticket related attacks is Rubeus. It has capabilities like Kerberos ticket requests, which retrieve a Ticket-Granting-Ticket (TGT) based on a user's password/hash in one instance or based on a user's certificate store. Rubeus can also be used for abusing constrained delegation in Windows domains by performing Service-for-User (S4U) constrained delegation within a specific domain or even across domains in a Forest.

From the example below, we can see that the threat actor is able to dump credential hash information from memory and locate a specific account name identified as an admin account. This account will be present because it would have logged on to that machine at some point.

This specific dump will also include information such as the logon server in the domain. This can be corroborated with the information gathered during the discovery phase to confirm the target domain controller.

In the example below, from the “itadmin” account NTLM hash which was dumped earlier, we have been able to pass this hash to launch a new Windows cmd process with the elevated admin privileged token. This means that the new cmd process can perform actions in the context of a privileged account even though the actual logged-in user may just have local admin rights on the compromised machine.

This new process will be running with the elevated token of the “itadmin,” which means that we can use it to run other remote access tools to target and connect to the domain controller over the network. In the image below, we can see that after a successful pass-the-hash attack, a secondary tool like power admin’s PAexec can be used to carry on the rest of the attack by connecting remotely to the domain controller. The hostname command in the image confirms successful lateral movement at both the application and network levels.

We can check the running services on the domain controller machine to verify that PAExec made a connection with a corresponding process. The pass-the-hash technique used to spawn the administrator-elevated token on the compromised laptop, which was then used to run the PAExec remote management tool, was successful as shown in the image below.

This is a simple demonstration of how attackers can move laterally, from the application level (credential theft in process memory) to the network level (smb, msrpc or http machine traversal), to reach the ultimate target – the domain controller.

ATT&CK: Impact

At this point, having reached the domain controller, the attacker is in charge. They can proceed to copy additional malicious files onto the domain controller remotely. For example, they could now copy Mimikatz onto the domain controller and use it to extract the built-in KRBTGT user account’s hash – in addition to other domain information – in order to launch the Golden Ticket attack. This can then be used for pass-the-ticket attacks across the entire domain.

The attacker can even use the tools already in place, living off the land to deploy something like ransomware and connect to other sensitive servers, like database or application servers, to further exfiltrate data. This could be PsExec, PowerShell, SCCM – any IT administration tool that can deploy software.

Depending on the sophistication of the attack, an attacker may use all custom tools or run code only in memory, so that signature analysis of tools like Mimikatz becomes difficult for any security tools to detect and prevent. In a similar vein, behavioural analysis can also be resource-heavy, so these analysis techniques may be disabled, especially in server environments or legacy operating systems that run legacy critical applications.

Tune in to our next post that examines mitigations for these attacks.